程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> JAVA編程 >> 關於JAVA >> Java Security Notes (6)

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.

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved