java代码审计常规漏洞 java代码审计常规漏洞有哪些

为什么java代码审计资料很少上面我写的是“熟悉” , 这只是对刚入行的同学说的,作为代码审计来说,熟练编写代码程序是必须的,要想深度化发展,精通一门语言是必经之路 。
知识一-变量逆向跟踪
在代码审计中,按业务流程审计当然是必须的,人工的流程审计的优点是能够更加全面的发现漏洞 , 但是缺点是查找漏洞效率低下 。如果要定向的查找漏洞,逆向跟踪变量技术就显得更加突出,如查找XSS、SQL注入、命令执行……等等 , 逆向查找变量能够快速定位漏洞是否存在 , 本次已SQL注入为例 。
什么是逆向跟踪
顾名思义,逆向跟踪就是对变量的逆向查找,开始全局查找出可能存在漏洞的触发点,然后回溯参数到前端,查看参数来源已经参数传递过程中的处理过程 。
什么不是java中易出现文件操作漏洞的方法web安全
Java代码审计——文件操作漏洞
?
jinyouxin
原创
关注
0点赞·152人阅读
?
目录
(一)、 文件操作漏洞简介
(二) 、漏洞发现与修复案例
2.1文件包含漏洞
2.2文件上传漏洞
(三) 文件下载/读取漏洞
(四).文件写入漏洞
(五).文件解压漏洞
小结
(一)、 文件操作漏洞简介
文件操作是 Java Web 的核心功能之一,其中常用的操作就是将服务器上的文件以流的形式在本地读写,或上传到网络上,Java 中的 File 类就是对这些存储于磁盘上文件的虚拟映射 。与我们在本地计算机上操作文件类似,Java 对文件的操作同样包括上传、删除、读取、写入等 。Java Web 本身去实现这些功能是没有漏洞的,但是由于开发人员忽略了一些细节 , 导致攻击者可以利用这些细节通过文件操作 JavaWeb 本身的这一个功能,从而实现形如任意文件上传、任意文件下载/读取、任意文件删除等漏洞,有的场景下甚至可以利用文件解压实现目录穿越或拒绝服务攻击等,对服务器造成巨大的危害 。
(二) 、漏洞发现与修复案例
2.1文件包含漏洞
文件包含漏洞通常出现在由 PHP 编写的 Web 应用中 。我们知道在 PHP 中,攻击者可以通过 PHP 中的某些包含函数 , 去包含一个含有攻击代码的恶意文件,在包含这个文件后 , 由于 PHP 包含函数的特性 , 无论包含的是什么类型的文件,都会将所包含的文件当作 PHP 代码去解析执行 。也就是说 , 攻击者可能上传一个木马后缀是 txt 或者 jpg 的一句话文件 , 上传后利用文件包含漏洞去包含这个一句话木马文件就可以成功拿到 Shell 了 。
那么 Java 中有没有类似的包含漏洞呢?回答这个问题前,我们首先来看一看Java 中包含其他文件的方式
JSP 的文件包含分为静态包含和动态包含两种:
静态包含:%@include file="test.jsp"% 。
动态包含:jsp:include page="%=file%"/jsp:include、c:import url="%=url%"/c:import
由于静态包含中 file 的参数不能动态赋值,因此我目前了解的静态包含不存在包含漏洞 。相反 , 动态包含中的 file 的参数是
java代码审计工程师是做什么的代码审计:顾名思义就是检查源代码中的安全缺陷,检查程序源代码是否存在安全隐患 , 或者有编码不规范的地方 , 通过自动化工具或者人工审查的方式,对程序源代码逐条进行检查和分析,发现这些源代码缺陷引发的安全漏洞 , 并提供代码修订措施和建议 。
java正则表达式怎么防止代码漏洞javaWeb安全漏洞及处理方式
关注
转载自java代码审计常规漏洞:
1、SQL注入攻击
SQL注入攻击就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串java代码审计常规漏洞,最终达到欺骗服务器执行恶意的SQL命令 。具体来说java代码审计常规漏洞,它是利用现有应用程序,将(恶意)的SQL命令注入到后台数据库引擎执行的能力,它可以通过在Web表单中输入(恶意)SQL语句得到一个存在安全漏洞的网站上的数据库 , 而不是按照设计者意图去执行SQL语句 。
随着B/S框架结构在系统开发中的广泛应用,恶意攻击者利用SQL命令在Web表单中输入合法的字符或查询字符串来欺骗服务器执行SQL命令 。当注入攻击得逞后,Web程序将泄露大量用户隐私数据和数据库中数据结构 。攻击者能够获得系统较高的访问权限,进行破坏操作 。
SQL注入可以分为平台层注入和代码层注入 。前者由不安全的数据库配置或数据库平台的漏洞所致;后者主要是由于程序员对输入未进行细致地过滤 , 从而执行了非法的数据查询 。基于此,SQL注入的产生原因通常表现在以下几方面:
1)不当的类型处理;
2)不安全的数据库配置;
3)不合理的查询集处理;
4)不当的错误处理;
5)转义字符处理不合适;
6) 多个提交处理不当 。
解决方法:
数据库安全通信包括SQL注入攻击的防范、安全设置、异常信息处理三个方面 。
1.服务端Filter对访问者输入的字符进行过滤检验,但是攻击者经常把危险字符潜藏在用户输入的有效字符中完 成过滤检验 。
2.通过正则表达式对页面的文本框输入的数据进行限制可以减少过滤检验存在的漏洞 。
3.使用prepareStatment预编译sql语句
2、XSS跨站脚本攻击
跨站脚本(Cross-site scripting,简称XSS),是一种迫使Web站点回显可执行代码的攻击技术,而这些可执行代码由攻击者提供、最终为用户浏览器加载 。不同于大多数攻击(一般只涉及攻击者和受害者),XSS涉及到三方,即攻击者、客户端与网站 。XSS的攻击目标是为了盗取客户端的cookie或者其他网站用于识别客户端身份的敏感信息 。获取到合法用户的信息后,攻击者甚至可以假冒最终用户与网站进行交互 。
XSS 属于被动式的攻击 。攻击者先构造一个跨站页面 , 利用SCRIPT、IMG、IFRAME等各种方式使得用户浏览这个页面时,触发对被攻击站点的HTTP 请求 。此时,如果被攻击者如果已经在被攻击站点登录,就会持有该站点cookie 。这样该站点会认为被攻击者发起了一个HTTP请求 。而实际上这个请求是在被攻击者不知情情况下发起的,由此攻击者在一定程度上达到了冒充被攻击者的目的 。精心的构造这个攻击请求,可以达到冒充发文 , 夺取权限等多个攻击目的 。在常见的攻击实例中,这个请求是通过script 来发起的,因此被称为Cross Site Script 。
XSS漏洞成因是由于动态网页的Web应用对用户提交请求参数未做充分的检查过滤,允许用户在提交的数据中掺入HTML代码(最主要的是“”、“”),然后未加编码地输出到第三方用户的浏览器,这些攻击者恶意提交代码会被受害用户的浏览器解释执行 。
分为三种类型:
1)反射型(数据流向:浏览器 -后端 - 浏览器)
反射型XSS脚本攻击即如我们上面所提到的XSS跨站脚本攻击方式 , 该类型只是简单地将用户输入的数据直接或未经过完善的安全过滤就在浏览器中进行输出 , 导致输出的数据中存在可被浏览器执行的代码数据 。由于此种类型的跨站代码存在于URL中,所以黑客通常需要通过诱骗或加密变形等方式,将存在恶意代码的链接发给用户,只有用户点击以后才能使得攻击成功实施 。
2)存储型(数据流向是:浏览器 -后端 - 数据库 - 后端- 浏览器)
存储型XSS脚本攻击是指Web应用程序会将用户输入的数据信息保存在服务端的数据库或其他文件形式中,网页进行数据查询展示时,会从数据库中获取数据内容,并将数据内容在网页中进行输出展示,因此存储型XSS具有较强的稳定性 。
存储型XSS脚本攻击最为常见的场景就是在博客或新闻发布系统中,黑客将包含有恶意代码的数据信息直接写入文章或文章评论中,所有浏览文章或评论的用户,都会在他们客户端浏览器环境中执行插入的恶意代码 。
3)基于DOM(数据流向是:URL--浏览器 )
基于DOM的XSS跨站脚本攻击是通过修改页面DOM节点数据信息而形成的XSS跨站脚本攻击 。不同于反射型XSS和存储型XSS , 基于DOM的XSS跨站脚本攻击往往需要针对具体的javascript DOM代码进行分析,并根据实际情况进行XSS跨站脚本攻击的利用 。
解决方法:
1).输入过滤 。对用户的所有输入数据进行检测,比如过滤其中的“”、“”、“/”等可能导致脚本注入的特殊字符,或者过滤“script”、“javascript”等脚本关键字,或者对输入数据的长度进行限制等等 。同时,我们也要考虑用户可能绕开ASCII码,使用十六进制编码来输入脚本 。因此,对用户输入的十六进制编码,我们也要进行相应的过滤 。只要能够严格检测每一处交互点,保证对所有用户可能的输入都进行检测和XSS过滤,就能够有效地阻止XSS攻击 。
2).输出编码 。通过前面对XSS攻击的分析,我们可以看到,之所以会产生XSS攻击,就是因为Web应用程序将用户的输入直接嵌入到某个页面当中,作为该页面的HTML代码的一部分 。因此,当Web应用程序将用户的输入数据输出到目标页面中时,只要用HtmlEncoder等工具先对这些数据进行编码,然后再输出到目标页面中 。这样,如果用户输入一些HTML的脚本,也会被当成普通的文字,而不会成为目标页面HTML代码的一部分得到执行.
3、CSRF跨站请求伪造漏洞防护
CSRF是CrossSite Request Forgery的缩写,乍一看和XSS差不多的样子 , 但是其原理正好相反,XSS是利用合法用户获取其信息 , 而CSRF是伪造成合法用户发起请求 。
字面理解意思就是在别的站点伪造了一个请求 。专业术语来说就是在受害者访问一个网站时 , 其 Cookie 还没有过期的情况下,攻击者伪造一个链接地址发送受害者并欺骗让其点击,从而形成 CSRF 攻击 。
根据HTTP协议 , 在HTTP头中有一个字段叫Referer , 它记录了该HTTP请求的来源地址 。在通常情况下 , 访问一个安全受限页面的请求必须来自于同一个网站 。
解决方案:
配置FILTER拦截用户所有请求(POST/GET),对用户请求Referer头URL进行合法性校验 。
4、URL链接注入漏洞防护
链接注入是修改站点内容的行为,其方式为将外部站点的 URL 嵌入其中,或将有易受攻击的站点中的脚本 的 URL 嵌入其中 。将URL 嵌入易受攻击的站点中,攻击者便能够以它为平台来启动对其他站点的攻击,以及攻击这个易受攻击的站点本身 。
解决方案:
1,二次验证,进行重要敏感操作时,要求用户进行二次验证 。
2,验证码,进行重要敏感操作时 , 加入验证码 。
3 , 验证 HTTP 的 Referer 字段 。
4,请求地址中添加 Token 并验证 。
5,HTTP 头中自定义属性并验证 。
5、会话COOKIE中缺少HttpOnly防护
会话cookie中缺少HttpOnly属性会导致攻击者可以通过程序(JS脚本、Applet等)获取到用户的cookie信息,造成用户cookie信息泄露,增加攻击者的跨站脚本攻击威胁 。
HttpOnly是微软对cookie做的扩展 , 该值指定cookie是否可通过客户端脚本访问 。Microsoft Internet Explorer 版本 6 Service Pack 1 和更高版本支持cookie属性HttpOnly 。
如果在Cookie中没有设置HttpOnly属性为true , 可能导致Cookie被窃取 。窃取的Cookie可以包含标识站点用户的敏感信息 。
如果在Cookie中设置HttpOnly属性为true,兼容浏览器接收到HttpOnly cookie,那么客户端通过程序(JS脚本、Applet等)将无法读取到Cookie信息,这将有助于缓解跨站点脚本威胁 。
解决方案:
配置filter拦截器 , 将服务器端返回请求,向所有会话cookie中添加“HttpOnly”属性 。
示例代码:
HttpServletResponseresponse=(HttpServletResponse)paramServletResponse;
response.setHeader("SET-COOKIE","JSESSIONID="sessionid"; HttpOnly");
6、点击劫持漏洞(Clickjacking)防护
点击劫持是一种视觉上的欺骗手段,攻击者使用一个透明的、不可见的iframe,覆盖在一个网页上,然后诱使用户在该网页上进行操作,此时用户在不知情的情况下点击了透明的iframe页面 。通过调整iframe页面的位置 , 可以诱使用户恰好点击在iframe页面的一些功能性按钮上 。
解决方案:
配置FILTER拦截器,在服务器端返回请求中,使用一个HTTP头“X-Frame-Options”值为SAMEORIGIN-同源策略,则frame页面的地址只能为同源域名下面的页面,防止点击劫持漏洞发生 。
示例代码:
HttpServletResponseresponse=(HttpServletResponse)paramServletResponse;
response.addHeader("x-frame-options","SAMEORIGIN");
7、HTTP host 头攻击漏洞
使用HTTP代理工具,可以篡改HTTP报文头部中HOST字段时,该值可被注入恶意代码 。因为需要控制客户端的输入 , 故该漏洞较难利用 。
解决方案:
配置FILTER拦截器,对请求输入HOST头信息进行信息安全性校验,防止HOST头信息被恶意篡改利用 。
示例代码:
HttpServletRequest request =(HttpServletRequest)servletRequest;
//主机ip和端口 或 域名和端口
String myhosts = request.getHeader("host");
if(!StringUtils.equals(myhosts, "xx.xx.xxx.xxx:xxxx")
!StringUtils.equals(myhosts, "xx.xx.xxx.xxx:xxxx")
!StringUtils.equals(myhosts,"xx.xx.xxx.xxx:xxxx")StringUtils.equals(myhosts,"xx.xx.xxx.xxx")
!StringUtils.equals(myhosts,"xx.xx.xxx.xxx")!StringUtils.equals(myhosts,"xx.xx.xxx.xxx" ){
logger.error("======访问host非法,已拦截======");
response.sendRedirect(request.getContextPath()"/login.jsp");
return;
}
8、越权访问漏洞防护
越权访问(Broken Access Control,简称BAC)是Web应用程序中一种常见的漏洞,分为垂直越权访问和水平越权访问 。垂直越权是指不同用户级别之间的越权,如普通用户执行管理员用户的权限 。水平越权是指相同级别用户之间的越权操作 。
Web应用程序如果存在越权访问漏洞,可能导致以下危害:
1)导致任意用户敏感信息泄露;
2)导致任意用户信息被恶意修改或删除 。
解决方案:
配置FILTER拦截器,对请求所有URL进行拦截,对于需要进行授权的URL进行权限校验,防止用户越权访问系统资源 。
9.弱口令漏洞
解决方案:最好使用至少6位的数字、字母及特殊字符组合作为密码 。数据库不要存储明文密码,应存储MD5加密后的密文,由于目前普通的MD5加密已经可以被破解,最好可以多重MD5加密,或者多种加密方式叠加组合 。
10.JSP页面抛出的异常可能暴露程序信息 。
有经验的入侵者,可以从JSP程序的异常中获取很多信息,比如程序的部分架构、程序的物理路径、SQL注入爆出来的信息等 。
解决方案:自定义一个Exception,将异常信息包装起来不要抛到页面上 。
11.本地缓存漏洞
合法用户“注销”后,在未关闭浏览器的情况下,点击浏览器“后退”按钮,可从本地页面缓存中读取数据 , 绕过了服务端filter过滤 。
解决方案:配置filter对存放敏感信息的页面限制页面缓存 。如:
httpResponse.setHeader("Cache-Control","no-cache");
httpResponse.setHeader("Cache-Control","no-store");
httpResponse.setDateHeader("Expires",0);
httpResponse.setHeader("Pragma","no-cache");
12.文件上传漏洞 。
前台仅使用JS对文件后缀做了过滤,这只能针对普通的用户 , 而恶意攻击者完全可以修改表单去掉JS校验 。
13.Java WEB容器默认配置漏洞 。
如TOMCAT后台管理漏洞 , 默认用户名及密码登录后可直接上传war文件获取webshell 。
解决方案:最好删除 , 如需要使用它来管理维护,可更改其默认路径 , 口令及密码 。
【java代码审计常规漏洞 java代码审计常规漏洞有哪些】关于java代码审计常规漏洞和java代码审计常规漏洞有哪些的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站 。

    推荐阅读