代码安全性检测java,代码安全检查
Java如何验证数据安全性?
对数据进行增删改操作的时候,会返回影响条数,可以根据这个判断。另外如果进行逻辑删除,根据需要可以判断这条数据是否已经被逻辑删除了,没有这个需求的话,可以直接update。
创新互联是一个技术型专业网络公司,致力于为广大企业、创业者打造切实有效的PC站、WAP站、APP站点等企业网站。无论是企业宣传的成都全网营销、致力于营销的电商网站、内容资讯分享的分类信息网站或其他类型网站,我们都从网站前期定位分析策划、技术架构,到网站界面设计、创意表现、站点架构搭建以及后续访问监控、维护、网站托管运营反馈建议等提供整套服务。
java语言包含那三种核心机制
Java语言包含三种核心机制:Java 虚拟机、垃圾收集机制和代码安全检测。
1、Java 虚拟机(Java Virtual Machine,JVM)
在一台计算机上由软件或硬件模拟的计算机。Java虚拟机读取并处理经编译过的平台无关的字节码class文件。
2、垃圾收集机制(Garbage collection)
在C/C++ 等语言中,由程序员负责回收无用内存。Java语言解除了程序员回收无用内存空间的责任。它提供一种系统级线程跟踪存储空间的分配情况。并在JVM的空闲时,检查并释放那些可被释放的存储器空间。垃圾收集在Java程序运行过程中自动进行,程序员无法精确控制和干预。
3、代码安全性检测(Code Security)
Java执行代码的时候,由JVM对运行的代码进行安全性检测,当进行一些非法操作的时候,比如修改一些系统设置的时候,JVM会发出警告。
下面有关java代码安全性的叙述哪些是对的
Ⅰ:字节码校验器加载查询执行需要的所有类。
Ⅱ:运行时解释器执行代码。
Ⅲ:在运行时,字节码被加载,验证后在解释器里面运行。
Ⅳ:类加载器通过分离本机文件系统的类和从网络导入的类增加安全性。
A.Ⅱ、Ⅲ
B.Ⅱ、Ⅲ、Ⅳ
C.Ⅰ、Ⅲ、Ⅳ
D.Ⅲ、Ⅳ
正确答案:B
如何安全检测Java Web应用网站漏洞
如何安全检测Java Web应用网站漏洞.txt32因为爱心,流浪的人们才能重返家园;因为爱心,疲惫的灵魂才能活力如初。渴望爱心,如同星光渴望彼此辉映;渴望爱心,如同世纪之歌渴望永远被唱下去。web开发应用程序(网站),是目前应用最广泛的程序。但是开发者的水平参差不齐,导致了各种各样web漏洞的出现。本文站在分层架构的角度,分析一下如何在java web程序中找到可能出现的种种漏洞。 本文讨论的只是web程序上的漏洞,和其它漏洞,是相对独立的。这句话看似废话,实际上却说明了时常被忽略的因素,即:“很多人认为只要我开发web程序没有漏洞,web服务器就安全了”,事实上,并非如此。一个合格的web程序开发人员,应该时刻清楚自己开发的程序会在什么环境中被使用,以及一旦自己的程序产生某种漏洞,最终会导致什么后果。简单的说,web程序被安装在一台或多台(分布式)web服务器上,一旦安装成功,就等于在为广大用户提供服务的同时,给入侵者打开了一条或N条新的思路。如果服务器管理员刚好对安全配置不了解(事实上,国内这种管理员居多),那么只好由我们的程序来守好最后的关卡最后一道防线。 看了本文题目,一定有一部分人会认为,“不就是讲JSP漏洞么,用得着披着这么厚的包装么?”,为了回答这个疑问,我们先看看JSP和ASP的开发有什么不同吧。在ASP时代(ASP,PHP等语言),开发一套系统往往比修改别人已经写好的系统痛苦的多,因为它们把所有的代码(包括链接数据库的代码、执行SQL语句的代码、控制页面显示的代码)统统都放在%......%中,我们时常会看到如下代码块: -----------代码来自某ASP SHELL----------- Function GetFileSize(size) Dim FileSize FileSize=size / 1024 FileSize=FormatNumber(FileSize,2) If FileSize 1024 and FileSize 1 then GetFileSize="font color=red" FileSize "/font KB" ElseIf FileSize 1024 then GetFileSize="font color=red" FormatNumber(FileSize / 1024,2) "/font MB" Else GetFileSize="font color=red" Size "/font Bytes" End If End Function ---------------------------------------- 如果客户的需求变了,要求页面不能使用“font color=red”等标签,全部应用“CSS”显示。挂了,把程序员召唤出来,一个一个的改吧。。。注意,这里强调下,特指“召唤程序员”才能改,如果是学美工的,只会HTML、JS、CSS,完了,这活还干不成。而这些只是简单的页面修改,如果客户今天说,MYSQL服务器承担不了这个数据量,要挂Oracle,可怜的程序员就要在一片一片的代码海洋里寻找执行SQL语句的代码,而每一个文件都可能存放着SQL语句,意味着每一个文件都可能在受SQL注入的威胁。
而JSP采用MVC模式分层架构进行开发,就可以把所有的文件分开,根据其用途,分别放在不同的文件夹下(分层),每个文件夹下的文件只负责自己的事情。例如数据访问层的代码就放在数据访问层的文件夹下,业务逻辑层的代码也都放在自己的文件夹下,当显示层(这一层是为了把最终的运算结果显示给用户看)的需求发生变化,就像前面的客户需求,我们只要修改这一层的文件就是了,其他层的代码根本不需要动,而修改者也不需要懂得其它层的代码。 代码分层了,意味着漏洞也在跟着分层,我们寻找JSP漏洞的思路也要跟着分层,才能与时俱进。 下面在讲述寻找漏洞的过程中,本文就拿一个简单的分层架构例子来做样板。样板程序的名称为“XX文章系统”,系统使用了STRUTS框架,和安全有关的层分为: “DB层”,这一层存放了链接数据库的字符串,以及JdbcTemplate类,直接访问数据库。因为在java中,执行SQL语句的函数按照返回值可以分为三类,所以在这一层定义了JDBC模版类(JdbcTemplate),每一次使用操作数据库时都要执行这一层的三个方法其中一个。 “DAO层(Data Access Object数据访问对象层)”,从安全角度上看,这一层存放了SQL语句(并不执行SQL语句,语句传给DB层执行)。这一层调用“DB层”访问数据库,它只知道“DB层”的存在,不知道数据库的存在。 “SERVICE层”,业务逻辑层,因为一个业务的实现,并不是一次数据库访问就可以完成的,所以这一层通过N次调用“DAO层的方法”实现业务逻辑,它只知道“DAO层”的存在,不知道“DB层”和数据库的存在。 “ACTION层”,调用业务逻辑层,根据返回的结果,控制JSP页面显示。它只知道业务层的存在。这一层是入侵者的攻击平台。 “Form层”,把用户POST提交的信息封装成Form对象,经过验证后提交给ACTION层处理。 “JSP层”(显示层),这一层是最终显示给用户看的页面,同时也是入侵者的攻击平台。 用户通过访问ACTION层,自动会发生:“ACTION调用SERVICE,SERVICE调用DAO,DAO调用DB,DB执行SQL语句返回结果给DAO,DAO返回给SERVICE,SERVICE返回给ACTION,ACTION把数据显示到JSP里返回给用户”。 有了样板,我们来分析这套程序中可能出现的各种web漏洞。 1、SQL注入漏洞 从SQL注入漏洞说起吧,在web漏洞里,SQL注入是最容易被利用而又最具有危害性的。怎么快速的找到呢?先分析流程,就拿用户查看文章这个流程为例:用户访问一个
action,告诉它用户想看ID为7的文章,这个action就会继续完成前面所说的流程。 如果是ASP程序,这就是最容易产生问题的时候,ASP是弱类型,接到参数后不需要转换类型,就和SQL语句连加起来。但是JSP就不一样,JSP是强类型的语言,接受有害的参数后:对于GET请求(直接在地址栏访问页面),如果这里要的是int型,即使不懂安全的程序员,也会把它(文章的ID)立刻转换成int,因为这里转换后在后面的处理中会更容易操作,而这时程序就出错了;对于POST请求,如果这里要的是int型,程序会在把它封装成Form对象时,因为自动要进行类型转化,同样发生错误,这两种错误发生后,根本不会访问后面的流程就跳出了,或许这就是JSP天生的安全性。所以,通常提交的变量是int时,不会发生问题,问题会出现在string参数这里,如果要查看某用户的信息,程序可能会让你提交如下参数:showuser.do? username=kxlzx。问题来了,因为这里是string类型,所以不懂安全的程序员顶多会判断一下是不是空,就连加成为SQL语句。有漏洞的程序大概会写成这个样子: ACTION的代码: showuser.do String username = null; username = request.getParameter("username"); Service service = new Service(); service.findByUsername(username); 得到参数后调用service,service层直接交给了Dao层,dao的代码: public Object findByUsername(String username) { JdbcTemplate jt=new JdbcTemplate(); String sql = "select * from Users where username=’"+username"’"; List list = jt.query(sql); ................... } dao调用了DB层的JdbcTemplate,把SQL语句拼好后,传给了JdbcTemplate去执行。不用再看这里的JdbcTemplate,就可以知道里面的代码使用了Statement的executequery()方法执行,导致了SQL注入。 分析了这么半天,有读者会问:“难道我要费这么大的力气才能找到漏洞么?”。的确,通常在ASP程序里找注入时的思路就是这样子,但是我们现在是在使用了开发模式分层架构的JSP程序里,应该按照分层架构的思维去找漏洞。在回答这个问题之前,我们还得绕个弯子,看看怎么在这里预防SQL注入(java始终都是这么优美,它不会直接告诉你答案,而是一层一层的让你拨开云雾)。 刚才分析流程,是从正向分析的,从用户输入到产生漏洞,我们在防御的时候,不妨倒过来看看,从DB层入手。JdbcTemplate调用执行SQL语句,可以有两个类供我们选择,一个是Statement,另一个就是预处理的Statement,两者有着效率上和安全上的显著差别。在效率上,只要数据库支持预处理技术(sqlserver,mysql,oracle等都支持,只有少数access等不支持),就会在大量执行SQL语句时增加速度;在安全上,使用预处理,会把接受的参数也经过预处理,从而不会作为SQL语句的一部分执行,而是仅仅作为SQL语句中的参数部分
内容被执行。一旦DB层使用了预处理,DAO层的SQL语句也会发生变化,成为这个样子: public Object findByUsername(String username) { JdbcTemplate jt=new JdbcTemplate(); String sql = "select * from Users where username=?"; List list = jt.query(sql,new Object[1]{username}); ................... } 这样,SQL注入就和我们的程序几乎无关了,注意我说的是几乎,而不是全部。知道了怎么防御,于是一切在这里变的简单极了,我们应该直接去DB层找到JdbcTemplate,看看代码,一旦使用了Statement,很好,这个系统十有八九有漏洞,下面要做的是使用Editplus搜索“request.getParameter”。没有使用预处理的系统,可能会在action层进行防御,对参数过滤,但总有防御不到的时候,因为战线拉的太长了,每一个action里都可能接受参数并存在漏洞。 还有一种情况,系统一部分使用了预处理,一部分没有,这样的情况可能是因为项目赶的比较仓促,人员没有经过正规培训,最后艰难的整合到了一起。这种情况也好办,直接在DAO层搜索("’)或(’"),这些符号用于和字符串变量连加,拼SQL语句,肯定是这些语句之后的代码使用了Statement。然后再往上层找,看看哪个action调用了这个有问题的dao类,也可能发生SQL注入。 即使系统使用了预处理,别忘了,程序给客户使用后,客户有权利去扩展的。程序拿到客户那里,客户有了新的需求,而这个需求又不大,很可能不愿意花钱重新雇人来实现扩展功能,在这个时候也可能出现问题,客户使用自己的程序员扩展AJAX功能,这个程序员因为怕出问题,不敢动源程序,就在web.xml里加了一个servlet,这个servlet直接去调用conn。可怕的事情发生了。所以,我们的搜索漏洞规则中又加上了一条,在非dao层的文件中,搜索“select,update,delete”等字符串。 2、暴露程序信息漏洞 这个漏洞是怎么来的呢?我们需要从异常说起。有经验的入侵者,可以从JSP程序的异常中获取很多信息,比如程序的部分架构、程序的物理路径、SQL注入爆出来的信息等,这个漏洞很容易防御,却很难快速定位漏洞文件。出现这样漏洞的时候,通常是我们在写代码的时候,少了一些可能性的考虑而导致的。这样的问题都是经验造成的,而寻找漏洞也要通过经验加运气(要有仙缘。。。),我个人技术有限,就不多说了。防御的方法就是在程序中加上“Exception层”,自定义异常,把系统产生的异常统统包装起来,不要放过任何一个可能产生异常的地方。像腾讯的异常就包装的很好“对不起,今天的注册人数已经达到十万,请您明天再来。。。”,废话,日注册量都十万,还让不让人活啦,铁定是程序发生了异常,不敢让各位大大们看到真实的面孔。
JAVA的安全性究竟怎样体现出来
java的安全性主要体现在:下载到本地的java applet只限制在java运行环境中,而不允许它访问计算机的其他部分。
这是由于java编译器输出的并不是可执行代码,而是字节代码(bytecode),java的运行系统就是java虚拟机,每个java程序的运行都是在java虚拟机的控制之下。java虚拟机可以包含这个程序并且阻止它在系统外产生副作用。通过java语言中的适当限制增强了安全性。
最受欢迎的软件安全性测试工具有哪些?
之前在做 国内软件测试现状调查 之时,因为安全性测试工具太多,结果显示其分布比较广,填写“其它”占的比重很高(66%),为此专门做了一个调查 ,虽然收集的有效反馈不多(不到100),但基本反映了测试工具的使用现状。
1. 从总体看,(静态的)代码分析工具和(动态的)渗透测试工具应用还是比较普遍 ,超过60%,而且渗透测试工具(73.68%)略显优势,高出10%。模糊测试工具,可能大家感觉陌生,低至16%,但它在安全性、可靠性测试中还是能发挥作用的。从理论上看,代码分析工具应该能达到95%以上,因为它易用,且安全性已经是许多公司的红线,得到足够重视。 希望以后各个公司能够加强代码分析工具和模糊测试工具的应用。
2. Java代码安全性分析工具前三名是 : IBM AppScan Source Edition(42.11%)、Fotify Static Code Analyzer(36.84%)、Findbugs(26.32%) ,而JTest、PMD等没进入前三名,虽然和第3名差距不大,只有5%左右。也有公司使用Checkmarx,不在此调查中。Coverity也支持Java,可能Java的开源工具较多,人们很少用它。
3. C/C++代码安全性分析工具前三名是 : C++Test(38.89%)、IBM AppScan Source Edition(38.89%)、Fotify Static Code Analyzer(27.78%)、Visual Studio(27.78%) 。Coverity、CppCheck、LDRA Testbed 没能进入前三名,可能LDRA Testbed比较贵,关键的嵌入式软件采用比较多,而Coverity Cloud针对Github等上面的代码有免费服务(),大家可以尝试应用。
4. JavaScript代码安全性分析工具应用最多的是 Google's Closure Compiler,其次是JSHint,也有的公司用Coverity来进行JS的代码分析。
5. Python代码安全性分析工具应用最多的是Pychecker ,其次是PyCharm,而Pylint使用比较少,也有几个公司用Coverity来进行Python的代码分析。
6. Web应用安全性测试的商用工具中,IBM AppScan异军突起 ,高达70%的市场,其它商用工具无法与它抗衡,第2名SoapUI和它差距在50%以上,HP webInspect 不到10%。
7. Web应用安全性测试的开源工具中,Firebug明显领先 ,将近50%,比第2名OWASP ZAP高12%,第三名是Firefox Web Developer Tools,超过了20%。
8. Android App的安全性测试工具中,Android Tamer领先 ,将近30%,比第2、3名AndroBugs、Mobisec、Santoku高15%左右。也有用其它不在调查项中的工具,总体看,Android App安全性测试工具分布比较散。
9. 网络状态监控与分析工具中,Wireshark遥遥领先,超过70%。 其次就是Tcpdump、Burp Suite,占30%左右。网络状态监控与分析工具挺多的,但从这次调查看,越来越集中到几个工具中,特别是Wireshark功能强,覆盖的协议比较多,深受欢迎。
10. SQL注入测试工具排在前三位的:SQLInjector、SQL Power Injector、OWASP SQLiX, 三者比较接近,差距在6%左右。其它两项工具Pangolin、SQLSqueal也占了10%,而Antonio Parata、Blind SQL Injections、Bsqlbf-v2、Multiple DBMS Sql Injection、Sqlninja几乎没什么人用。
安全性测试工具很多,还包括黑客常用的一些工具,如暴力破解口令工具、端口扫描工具、防火墙渗透工具、渗透测试平台等。从某种意义看,它们超出软件范畴,更多属于网络空间安全、密码学等范畴,在此就不展开了。概括起来最受欢迎的软件安全性测试工具有:
文章标题:代码安全性检测java,代码安全检查
文章路径:http://pwwzsj.com/article/dsgcijc.html