代码java画图板

Java安全编程(BadExamplesfoundinJDK)MarcSchnefeld,UniversityofBambergIllegalaccess.
org关于演讲者MarcSchnefeld,Diplom-WirtschaftsinformatikerForScience:Externaldoctoralstudent@LehrstuhlfürpraktischeInformatikatUniversityofBamberg,Bavaria,Germany课题项目:REFACTORINGOFSECURITYANTIPATTERNSINDISTRIBUTEDJAVACOMPONENTSForLiving:DepartmentforOperationalSecurityManagementatcomputingsiteforlargefinancialgroupinGermanyJava,J2EE,CORBA[CSMR2002]设计和开发安全加固(代码审核)情形Java(我们这里讨论适用于J2SE,一些方面也适用于J2EE)被设计成一种具有与生俱来安全特性的编程语言[Gong,Oaks]JVM级:类型安全(TypeSafety),字节码完整性检测(Bytecodeintegritychecks)API级:SecurityManager,ClassLoader,CertPath,JAAS加密支持:JCA/JCE,JSSE所以,什么会是问题呢一些2003/2004年的Java安全警告Java运行时环境(RuntimeEnvironment)可能允许非受信Applets提升权限JavaMediaFramework(JMF)中的一个漏洞,可能导致Java虚拟机(JVM)崩溃…JavaRuntimeEnvironment远程拒绝服务攻击漏洞(DoS)…尽管存在JAVA安全体系的先天防护,还是有许多潜在的攻击可能性…是什么原因导致的呢FL2FL3幻灯片4FL2警告FlierLu,2005-8-16FL3不被信任FlierLu,2005-8-16问题一个平台(象Javaruntimeenvironment)只能提供对程序员意图的支持什么是程序员的意图表现出不同的观点…功能[应用程序员]Java有一套很强大的预定义的API函数(sockets,files,…)质量和重用[中间件程序员]Java在不同的语义级别提供通讯和编组(marshalling)能力(Sockets,RMI,CORBA,Raw-Serialisation,XML-Serialisation,…)安全性[安全架构师]Java在沙箱(sandbox)外提供隔离、加密和安全Sockets等支持恶意的意图[敌人]通过找到弱点来破坏安全JavaVM和核心的lib库有(许多)漏洞Classloaders和保护域为什么在JAVA代码中找安全漏洞基于组件的软件开发第三方的中间件组件(web服务器,图像库,PDF生成,…)随处可见我们在受信任的地方(根类型加载器bootclassloader)重用它们但是我们真的能信任它们吗疑问:我的第三方图像库中是否存在可能被攻击者利用的存在漏洞的对象实现JDK是否把我隔离存放的机密XML数据,与其他存在恶意代码的applets加载到同一个JVM中对象序列化(serialisation)真的安全么J2EE多层应用类型J2EE多层攻击类型EvilTwinAttack数据注入攻击(SQL,遗留格式)拒绝服务攻击,恶意序列化数据Java安全模式Sun的安全编码指导方针(最后更新于2000年2月2日!
):1.
小心使用特权代码2.
小心处理静态字段3.
最小化作用域(scope)4.
小心选择公共(public)方法和字段5.
适当的包(package)保护性6.
尽可能使用不可变(immutable)对象7.
永远不要返回对包含敏感数据的内部数组的引用8.
永远不要直接存储用户提供(user-supplied)的数组9.
小心使用序列化(Serialization)10.
小心使用本地方法(nativemethods)11.
清除敏感信息http://java.
sun.
com/security/seccodeguide.
htmlJava安全反模式忽略那些安全模式的代码不经意间就会造成漏洞典型的Java安全编码反模式(Antipatterns):忽略语言特性(例如整数溢出(IntegerOverflow))不注意使用序列化,不注意使用特权代码将字段和方法定义到不适当的可见性作用域在非终态(non-final)静态字段中的隐蔽通道(CovertChannels)他们隐藏在你自己的代码和你使用的库中出于学术兴趣,我们审查了SunJDK1.
4.
x的部分代码,下面将介绍我们的发现:如何在JAVA代码中找安全隐患测试程序是否需要已指定的许可权限,在逆向分析受保护域时很有用.
jChains(http://jchains.
dev.
java.
net)策略评估工具字节码检测器(访问者模式):预定义(软件质量)自定义(安全审计)Findbugs(基于ApacheBCEL)字节码审计分析器耗时的分析工作,且需要经验JAD(!
),JODE反编译器只在源代码完全可用情况下有用[大部分情况不是这样的]PMD,Checkstyle源代码检测工具字节码分析器以下讨论基于JVM字节码分析器Findbugs(http://findbugs.
sourceforge.
net)针对java代码检测bug模式的静态检测器(detector)由马里兰大学开发(Puth和Hovemeyer)开源项目基于BCEL(ApacheBytecodeEngineeringLibrary)通过访问者模式分析:类的结构与继承控制和数据流GUI/命令行界面可扩展,允许编写自己的检测器Java安全反模式反模式(错误,缺陷)在受信代码中(例如rt.
jar)导致漏洞出现可用性:AP1:整数溢出,未知类型(java.
util.
zip.
*)AP2:序列化(Serialisation)的副作用(java.
io.
*)完整性:AP3:特权代码副作用(引诱打破沙箱的攻击)AP4:不恰当的作用域(违反访问控制)AP5:非终态静态变量(在applets之间的隐蔽通道)机密性:AP6:重用非安全组件(org.
apache.
*,在applets间嗅探私有的XML数据)目标:定义一个二进制审计工具集,用来在你自己的代码和你使用的库中检测反模式以修复安全漏洞.
Java反模式1:整数溢出如blexim(Phrack#60)所述,整数溢出在C/C++中是个严重的问题,在Java中也同样如此:所有Java整数被限制在[-231,+231-1]的范围内在Java中,以下成立:-231=231+1沉默溢出(SilentOverflow)是问题所在:因为符号改变不会被报告给用户,也没有JVM标志被设置JDK1.
4.
1_01代码是基于这样一个错误的假设:java整数是极大的.
这将导致在java.
util.
zip包产生一系列的安全问题Java反模式1:整数溢出下列调用当参数x>yx,y≥0时,会导致崩溃tuple(newbyte[0],x,Integer.
MAX_VALUE-y)è可通过愚弄参数检查,来使在受信JDK函数中的数据沉默溢出(silentoverflow),所以核心lib库和JVM都检测不到该溢出.
è本地方法调用——updateBytes访问字节数组将导致一个非法内存访问错误.
通常JVM会崩溃.
D:\>javaCRCCrashAnunexpectedexceptionhasbeendetectedinnativecodeoutsidetheVM.
UnexpectedSignal:EXCEPTION_ACCESS_VIOLATIONoccurredatPC=0x6D3220A4Function=Java_java_util_zip_ZipEntry_initFields+0x288Library=c:\java\1.
4.
1\01\jre\bin\zip.
dllCurrentJavathread:atjava.
util.
zip.
CRC32.
updateBytes(NativeMethod)atjava.
util.
zip.
CRC32.
update(CRC32.
java:53)atCRCCrash.
main(CRCCrash.
java:3)Dynamiclibraries:0x00400000-0x00406000c:\java\1.
4.
1\01\jre\bin\java.
exe[.
.
.
linesomitted.
.
.
]0x76BB0000-0x76BBB000C:\WINDOWS\System32\PSAPI.
DLLLocalTime=MonMar1714:57:472003Java反模式1:整数溢出CRC32类允许计算缓冲区的校验和:假如有一个字节缓冲区(1,2,3,4),要计算它的校验和,你需要调用:CRC32c=newjava.
util.
zip.
CRC32();c.
update(newbyte[]{1,2,3},0,3);但是,在你做以下操作的时候:c.
update(newbyte[0],4,Integer.
MAX_VALUE-3);将导致JDK1.
4.
1_01和JDK1.
3.
1等版本的JVM崩溃Java反模式1:整数溢出,风险和范围风险:假如攻击者能在一个多用户共享JVM的环境中(例如Domino服务器或TomcatHTTP服务器)利用那些函数的话,那么就能造成拒绝服务攻击范围:更多受信函数被发现有漏洞:java.
util.
zip.
Adler32().
update();java.
util.
zip.
Deflater().
setDictionary();java.
util.
zip.
CRC32().
update();java.
util.
zip.
Deflater().
deflate();java.
util.
zip.
CheckedOutputStream().
write();java.
util.
zip.
CheckedInputStream().
read();java.
text.
Bidi.
;http://developer.
java.
sun.
com/developer/bugParade/bugs/4811913.
htmlalsobugnr={4811913,4812181,4812006,4811927,4811917,4982415,4944300,4827312,4823885}Java反模式1:整数溢出,重构publicvoidupdate(byte[]b,intoff,intlen){if(b==null){thrownewNullPointerException();}if(offb.
length-len){thrownewArrayIndexOutOfBoundsException();}crc=updateBytes(crc,b,off,len);}AfterJDK1.
4.
102publicvoidupdate(byte[]b,intoff,intlen){if(b==null){thrownewNullPointerException();}if(offb.
length){thrownewArrayIndexOutOfBoundsException();}crc=updateBytes(crc,b,off,len);}BeforeJDK1.
4.
101Java反模式1:整数溢出,重构(字节码)12:iload_213:iflt2816:iload_317:iflt2820:iload_221:aload_122:arraylength23:iload_324:isub25:if_icmple36After(1.
4.
1_02)12:iload_213:iflt2816:iload_317:iflt2820:iload_221:iload_322:iadd23:aload_124:arraylength25:if_icmple36Before(1.
4.
1_01)整数溢出字节码模式重构后字节码Java反模式1:对有害的整数溢出,如何在审核过程中发现它1.
通过侦测iadd指令来找潜在的问题方法2.
iadd是否使用用户提供的数据(使用的堆栈数据是否来源于iload)来执行一个范围检查3.
是否随后用同样的数据调用一个本地方法(invokevirtual,invokestatic)该过程可以使用Findbugs字节码检测器来实现AP1:结论和建议不象一般的x86处理器那样(设计于1978年),JVM没有提供一个溢出标志,所以没有办法在运行的时候侦测这种情况.
而在27年后设计的Java1.
5中(aka5.
0akaTiger),JVM仍没有解决这个问题对JDK6.
0的建议:为了避免给程序员(没有安全意识的)增加负担,有界基本整数类型(boundedprimitiveinteger)会非常有帮助(象ada那样).
subtypeMonth_TypeisIntegerrange1.
.
12;如果这对java编译器的处理来说太复杂的话,至少也应提供编译警告列出潜在的溢出威胁.
(是否可能在Java6.
0中出现)反模式2:序列化的副作用创建一个java对象的一般方法是使用new指令,它将调用类的构造函数.
但是:Java序列化API(java.
io包的一部分)允许跳过构造函数来创建此对象类型的新实例,只需要简单的将数据发送到一个与socket,文件或字节数组绑定的java.
io.
ObjectInputStream(OIS)OIS对象一般被远程通讯(如RMI)或持久化框架,用于将预先构建的对象导入到JVM当一个对象从一个OIS中被读出的时候,大部分继承的readObject方法会被调用.
AP2:风险和范围风险读取序列化后的对象可能迫使JVM进入一个复杂的,容易出现漏洞代码的区域,而此过程会在readObject方法中被所调用.
readObjectmethods可能位于在你自己的代码,JDK类中以及你所使用到的任何的第三方库中.
攻击者可能准备了手工处理过的数据包作为序列化数据.
范围在WIN32平台上导致JVM崩溃java.
awt.
font.
ICC_Profile触发一个未处理的OutOfMemoryError错误,它将终止当前监听的线程使服务失效.
(作为一个错误,它将跳过try/catch的检查)java.
util.
HashMap触发复杂的计算,JVMmaybecomeunresponsive"[SunAlert57707]java.
util.
regex.
PatternAP2:风险和范围http://classic.
sunsolve.
sun.
com/pub-cgi/retrieve.
pldoc=fsalert%2F57707http://classic.
sunsolve.
sun.
com/pub-cgi/retrieve.
pldoc=fsalert%2F57707AP2:序列化的副作用,重构privatevoidreadObject(java.
io.
ObjectInputStreams)throws…{s.
defaultReadObject();//InitializecountsgroupCount=1;//iflength>0,localCount=0;//使用延后(lazily)编译的模式compiled=false;if(pattern.
length()==0){root=newStart(lastAccept);matchRoot=lastAccept;compiled=true;}}AfterJDK1.
4.
206privatevoidreadObject(java.
io.
ObjectInputStreams)throws…{s.
defaultReadObject();//InitializecountsgroupCount=1;localCount=0;//Recompileobjecttreeif(pattern.
length()>0)compile();//sowecompileforthenext1600yearselseroot=newStart(lastAccept);}BeforeJDK1.
4.
205AP2:如何在审核过程中发现它1.
通过侦测readObject定义来找到潜在的问题类型.
2.
对于那些类来说,看是否控制流落入到有害的代码中I.
搜寻算法复杂度.
(是否要用800年来编译一个正则表达式)II.
搜寻无穷循环(bytecodebackwardbranches)III.
代码是否调用了易受攻击的nativecode并且把全部或者部分的负荷传给了它Findbugsbytecodedetector可实现该过程.
AP2:结论和建议readObject方法主要被设计用来接受和检查序列化(Serializable)的数据嵌套的Serializable类型会发生嵌套的readObject调用,所以恶意符合(payload)不必一定要在根对象中.
尝试将复杂操作从创建时推迟到第一次使用时同样的规则也适用于readExternal方法,该方法实现Externalizable接口的接收部分.
AP3:特权代码的副作用基本的Java访问逻辑:在如下情况,访问请求才被允许:当前执行上下文中,每个保护域都已经获得许可指定权限;换句话说,每一个保护域中的代码和主体都获得指定权限.
只有当所有的保护域Di包含权限p的时候,权限才能被获得∈=iniDp1IAP3:特权代码的副作用特权代码(doPrivileged)可被用来跳过堆栈逻辑检查在应用/用户(userclasses)级需要的许可,跟在执行必要的中间件/系统级(rt.
jar)的许可是不一样的.
üAP3:特权代码的副作用:风险和范围风险一个attacker可能滥用该条件来提升权限并且脱离受限的保护域(例如JNLP或applet沙箱)他知道JDK中的特权代码块,并且给应用程序的codesources以特权.
通过一个引诱,攻击者试着诱骗控制到特权的代码块并且让该特权块使用他注射进来的payload范围….
…把临时文件(例如可执行文件)传输到客户端的机器上,然后在合适的时候去执行(http://www.
derkeiler.
com/Mailing-Lists/Full-Disclosure/2004-07/0462.
html)java.
awt.
Font(i)使用内容为全零数据的大文件填充客户端机器的剩余磁盘空间Java.
awt.
Font(ii)脱离applet沙箱并测试客户端机器是否存在某文件.
java.
awt.
font.
ICC_ProfileAP3:特权代码的副作用:风险和范围AP3:重构没有可用的修复前面描述的bugs依然存在在于JDK中,所以很不幸,没有可用的修复尽管在Q2/2004或者更早,那些漏洞就已报告给SunAP3:特权代码的副作用:如何审核1.
通过检查doPrivileged调用找出潜在的问题类型2.
对于那些类,确认用户提供数据是否传递到特权代码块中假如是的话会导致I.
非受信任的代码访问到受保护资源II.
把秘密数据泄露给非受信任的代码III.
让非受信任代码执行不希望的修改Findbugs字节码检测器可以部分实现这个过程.
AP3:结论和建议结论doPrivileged对保护域来说是强大的但是危险的双刃剑建议对Sun:请修复在JDK特权代码中的bugs对组件用户:在使用前,请检查第三方库中的doPrivileged块,因为他们可能打破你制订的安全策略对中间件开发者:使你代码中的特权代码尽可能短小[http://java.
sun.
com/security/seccodeguide.
html]在传给特权代码前,请检查用户提供的数据有效性AP4:不恰当的作用域(Scope)作为一条规则,尽可能的减小方法和字段的作用域范围.
检查包私有(package-private)成员是否应该是私有(private),保护(protected)成员是否应该是包私有或私有等等.
[SunSecurityCodeGuidelines]当你设计一个受信的JDK扩展(例如JavaMediaFramework(JMF))的时候,该规则由为重要.
AP4:不恰当的作用域:风险和范围风险攻击者能利用受信的保护域(jre/lib/ext中的java扩展)的AllPermissions来提升权限,例如JMF安装额外受信的类到jre/lib/ext通过本地(native)方法访问系统内存公共的JMF类com.
sun.
media.
NBA暴露了一个指向物理内存的公共指针[longvaluedata]所以不受信任的applets也可以读你的系统内存AP4:不恰当的作用域:风险和范围http://classic.
sunsolve.
sun.
com/pub-cgi/retrieve.
pldoc=fsalert%2F54760http://classic.
sunsolve.
sun.
com/pub-cgi/retrieve.
pldoc=fsalert%2F54760AP4:不恰当的作用域:重构123publicfinalclassNBA{protectedfinalsynchronizedvoidfinalize()publicsynchronizedObjectgetData()publicsynchronizedObjectclone()publicsynchronizedvoidcopyTo(NBAnba)publicsynchronizedvoidcopyTo(bytejavadata[])privatelongdata;privateintsize;privateClasstype;}After(JMF2.
1.
1e)publicclassNBA{publicvoidfinalize()publicObjectgetData()publicObjectclone()publicvoidcopyTo(NBAnba)publicvoidcopyTo(bytejavadata[])publiclongdata;publicintsize;publicClasstype;}Before(JMF2.
1.
1c)1)应该禁止对此类的继承,以防止新方法去泄露机密数据.
2)public的finalize方法的作用域被降为protected,所以没有类能覆盖它3)数据字段被移到了适当的private(class级别)作用域AP4:不恰当作用域的副作用:如何审查1.
通过探测public类型来找潜在的问题类型2.
对于那些类型,判定:I.
数据字段定义为publicII.
方法定义为publicIII.
public方法返回一个private,protected内部数据的引用Findbugs的预定义检测器可实现定位潜在的问题类型.
AP4:结论和建议结论在方法和字段上不恰当的作用域可能导致跳过访问控制机制建议[http://java.
sun.
com/security/seccodeguide.
html]避免使用public变量,而是通过接口的访问方法(accessormethods)来访问内部变量.
通过这种方式,在需要的时候可以很容易增加特定的安全检查(centralizedsecuritychecks).
确认任何public方法访问并/或修改任何敏感内部数据的时候包括安全检查.
AP5:非终态静态变量避免使用非终态(non-final)公共静态变量(staticvariables)尽可能不使用非终态公共静态变量,因为没有机制来检测改变此变量的代码是否有适当的权限.
一般情况下,小心对待任何易变的静态状态,它能导致在两个设计上相互独立的子系统间出现不希望的交互.
[SunSecurityCodeGuidelines]根据SunMicrosystems[http://www.
sun.
com/software/security/glossary.
html]术语covertchannel定义如下:设计上并非用来进行数据通讯的通讯通道.
它允许进程以违背安全策略意图的方式间接的传递信息.
我们将展示粗心的使用静态变量这样一个反模式的情景,可能导致恶意代码利用保护域间隐蔽通道进行通讯.
AP5:非终态静态变量,风险与范围风险StaticVariables(被bootclassloader(liketheonesinrt.
jar)或者是扩展的classloader装载)在一个JVM中是一个单件(singleton)Non-finalstaticString字段可能会把序列化好的java对象传给没有权限访问它们的其他保护域.
BrowserVMAppletfromsiteAAppletfromsiteBProtectionDomainBProtectionDomainAProtectionDomain/lib/rt.
jarAllPermissions"org.
apache.
xalan.
processor.
XSLProcessorVersion.
LANGUAGEorg.
apache.
xalan.
processor.
XSLProcessorVersion.
S_VERSIONjavax.
swing.
JDesktopPane.
LIVE_DRAG_MODE.
.
.
Serialobj.
Serialobj.
AP5:非终态静态变量,风险与范围http://www.
heise.
de/newsticker/meldung/41308UnsignedJava-AppletsjumpoutofSandboxhttp://www.
heise.
de/newsticker/meldung/41308UnsignedJava-AppletsjumpoutofSandboxAP5:非终态静态变量:重构publicclassorg.
apache.
xalan.
processor.
XSLProcessorVersion{publicstaticfinaljava.
lang.
StringPRODUCT;publicstaticfinaljava.
lang.
StringLANGUAGE;publicstaticfinalintVERSION;publicstaticfinalintRELEASE;publicstaticfinalintMAINTENANCE;publicstaticfinalintDEVELOPMENT;publicstaticfinaljava.
lang.
StringS_VERSION;}After(JDK1.
42_05)publicclassorg.
apache.
xalan.
processor.
XSLProcessorVersion{publicstaticfinaljava.
lang.
StringPRODUCT;publicstaticjava.
lang.
StringLANGUAGE;publicstaticintVERSION;publicstaticintRELEASE;publicstaticintMAINTENANCE;publicstaticintDEVELOPMENT;publicstaticjava.
lang.
StringS_VERSION;}Before(JDK1.
42_04)final修饰符的变量在初始化后就不允许修改.
最初,他们仅使用它来保护他们的产品名称JAP5:非终态静态变量:如何审核1.
findbugs内建的检测器通过查询public类型来找潜在的问题类型2.
对于那些类,我们需要找出I.
基础数据字段和String定义为publicstatic,non-finalII.
对象类型数据字段,数组,容器定义为publicstaticIII.
允许访问(I+II)中的non-public实例的方法AP5:结论和建议结论Non-finalstatic字段允许在两个保护域间建立隐蔽通道,跳过诸如applet沙箱(sanbox)这样的约束.
建议[http://java.
sun.
com/security/seccodeguide.
html]尽可能不要使用non-finalpublicstaticvariables,因为没有机制来检查改变该变量的代码是否有适当的权限.
一般的,小心的对待那些易变的staticstates,因为它可以在两个本来独立子系统间触发希望的交互.
反模式6:重用非安全组件分布式基于组件的应用可以由不同提供商提供的软件组件所组成.
因此必须区分应用本身和软件组件提供商,他们需要有不同的保护策略":[Hermann,Krumm]第三方的组件可能是根据程序员想要的功能的;然而,JDK的限制执行模型的控制管理需要安全,而不单单是功能.
JDK(作为一个component-structured中间件应用)从Apachefoundation那里拿来了许多XML的功能.
对于嵌入到JDK中的第3方组件,是否有足够的保护来对抗弱点呢AP6:重用非安全组件:风险与范围风险嵌入到JDK中的XSLTparser是直接从原先apacheXALAN独立版本拿过来的,可从http://xml.
apache.
org下载此版本具有很强的可配置性,特别是允许自定义函数,在XSLT(extensiblestylesheetlanguagetransformations)中被调用.
在受信的库中的Non-finalstatic数组可能包含对象,允许把该对象传递到JVM的各个地方.
下面我们将展示重用非安全组件这样一个反模式,允许恶意代码通过插入恶意回调函数获得受信代码权限AP5:Non-FinalStaticVariables,Risk&Extendhttp://classic.
sunsolve.
sun.
com/pub-cgi/retrieve.
pldoc=fsalert%2F57613http://classic.
sunsolve.
sun.
com/pub-cgi/retrieve.
pldoc=fsalert%2F57613AP6:重用非安全组件:重构publicclassorg.
apache.
xpath.
compiler.
FunctionTable{privatestaticorg.
apache.
xpath.
compiler.
FuncLoader[]m_functions;[.
.
.
]}After(JDK1.
42_06)publicclassorg.
apache.
xpath.
compiler.
FunctionTable{publicstaticorg.
apache.
xpath.
compiler.
FuncLoader[]m_functions;[.
.
.
]}Before(JDK1.
42_05)该重构把组件的增强功能调整到这样的水平:在受限的执行模式中能够安全的运行.
技术上来说,该重构修复了反模式4和反模式5的问题.
private修饰阻止恶意代码对XSLT解析器内建函数表的修改.
AP6:重用非安全组件:如何审查1.
第三方组件可能包括所有类型的反模式,以我们的经验至少应该检查下列的现存反模式1.
检查Integer溢出2.
检查正确的序列化,注意其副作用3.
检查特权代码的使用,特别是当使用特权或"AllPermission"保护域(protectiondomains).
4.
调整不合适的作用域,给公共可用的字段和功能加安全检查.
5.
在staticnon-final字段和staticmutable容器类型上关闭隐蔽通道(也包括间接使用).
AP6:结论和建议结论即使你自己的代码是安全的,第3rd方的组件可以摧毁你的安全堡垒建议向你要重用的提供商询问,是否有用过findbugs或者类试的工具检查过他们的组件在你购买之前要求一个findbugs的报告,这可能增加对组件的信任.
许多开源的项目已经包括了类试这样一个报告,一些闭源软件的开发者应该学习下.
finally{}下载www.
illegalaccess.
org发布的检测器给我发eMailmarc@marc-schoenefeld.
com联系方式