Java Security Notes (6)
类别: JAVA教程 
The five segments of notes take me three days to recall the basic knowledge of Java Security Mechanism--sandbox. But I like the language itself. Because I could control everything. Once your administrator set up environment for you, when you hope to get more authorization and right, you have to write e-mail, fill application form and ask your boss to approve it. What\'s troublesome nuts!
So I will start new topic--Java Languages Security. This is more interesting for me and more comfortable to express what I try to explain. But I don\'t discuss those exceptions such as native code that always trigger the problem as it\'s more like C/C++ code instead of Java code. As we all know, C/C++\'s secuirty reply on yourself majorly.
Please remember these:public, protect, private, final . They are much better than C++. Because programmer haven\'t pointer to help them to snoop on hidden components in the class. Another good news is that Java forbid to arbitrarily cast class type unless there is some relationship between them such as derivative. Of course , you still can not stop memory snooper. What a pity!
The second bonus or maybe danger is object serialization. The file stored in hard disk. A lot of crazy guys could read it after trying with many times. How can we cope with it? One is to avoid from using it. The other is to encode them and override the writer and loader function.
The third tool is Javac , compiler tool. It can help to check security but weak functionality.
The forth trouble is from Java language itself. This problem is like Hook technique which have been used in network card capture application or API replacement. From the Java view, this is more easier than C++. Because there is one virtual machine used for application. Sun adds one bytecode verifier into virtual machine to detect corrupted code or illegal code. But Java uses special skill to do such detection--to verify bytecode only when the bytecode is performing. But it\'s not the runtime check. The real runtime check does not check class attribute but check array bounds and object casting.
As author said that the notion of security in Java is pervasive, its implementation is equally pervasive.
So I will start new topic--Java Languages Security. This is more interesting for me and more comfortable to express what I try to explain. But I don\'t discuss those exceptions such as native code that always trigger the problem as it\'s more like C/C++ code instead of Java code. As we all know, C/C++\'s secuirty reply on yourself majorly.
Please remember these:public, protect, private, final . They are much better than C++. Because programmer haven\'t pointer to help them to snoop on hidden components in the class. Another good news is that Java forbid to arbitrarily cast class type unless there is some relationship between them such as derivative. Of course , you still can not stop memory snooper. What a pity!
The second bonus or maybe danger is object serialization. The file stored in hard disk. A lot of crazy guys could read it after trying with many times. How can we cope with it? One is to avoid from using it. The other is to encode them and override the writer and loader function.
The third tool is Javac , compiler tool. It can help to check security but weak functionality.
The forth trouble is from Java language itself. This problem is like Hook technique which have been used in network card capture application or API replacement. From the Java view, this is more easier than C++. Because there is one virtual machine used for application. Sun adds one bytecode verifier into virtual machine to detect corrupted code or illegal code. But Java uses special skill to do such detection--to verify bytecode only when the bytecode is performing. But it\'s not the runtime check. The real runtime check does not check class attribute but check array bounds and object casting.
As author said that the notion of security in Java is pervasive, its implementation is equally pervasive.
