首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

常见代码安全漏洞分析及处理

最近几年你要问我最火的专业是什么,我会毫不犹豫告诉你:计算机软件工程,从O2O、P2P火爆开始,到大数据AI,再到现在区块链颠覆性技术,互联网软件行业经历着一个又一个重大革新,而同时安全漏洞事件造成的影响也在持续升级,最近facebook隐私泄露持续发酵,无不让人越来越重视信息安全。

本文主要给大家分享一些在项目中遇到的java安全编码漏洞及解决方法。

1、SQL注入

攻击原理:

攻击者通过构造恶意SQL命令发送到数据库,如果程序未对用户输入的 SQL命令执行判断过滤,那么生成的SQL语句可能会绕过安全性检查,插入其他用于修改后端数据库的语句,并可能执行系统命令,从而对系统造成危害。

关于SQL漏洞现在大家编码习惯上来之后,这一块漏洞已经减少很多,这里只是提一下mybatis防SQL注入原理:

#{}:相当于JDBC中的PreparedStatement

${}:是输出变量的值

#{}是经过预编译的,是安全的;${}是未经过预编译的,仅仅是取变量的值,是非安全的,存在SQL注入。

2、越权漏洞

越权分为水平越权和垂直越权、交叉越权。何为垂直越权?

垂直越权:它是纵向的,是基于角色的控制(role-Based Access Control 简称RBAC)。简单的说,垂直越权即低权限的角色通过一些途径,获得高权限的能力,就发生了越权访问。一般在配置权限时应该采用“最小权限原则”。

水平越权:相对垂直越权,他是水平的,是基于数据的控制访问。简单的说,水平越权就是同等角色下的用户,不但能够访问自己私有的数据,还能访问其他人私有的数据。

交叉越权:交叉越权是垂直越权和水平越权的交集。

很好理解,说到底就是用户获得了不属于他自己的操作权限。

解决方案:解决方案也相对简单,只有查询权限就不能增、删、改的权限,对数据的操作均应该校验该角色是否具有该操作权限。

3、XSS漏洞

定义:

XSS是跨站点脚本攻击(Cross site scripting)和层叠样式表(Cascading style sheets)的缩写混淆,指攻击者往web页面插入恶意脚本,网站设计输入输出时未对用户输入进行过滤,当用户浏览该页面时,嵌入其中的恶意脚本被执行,从而达到恶意攻击用户的目的。

分类:

1)基于DOM(Document Object Model)的XSS:DOM的树形结构会动态的将恶意代码嵌入页面,框架,程序或API而实现的跨站攻击。

2)反射式XSS(非持久性XSS):恶意脚本未经转义被直接输入并作为HTML输出的一部分,恶意脚本不在后台存储,直接在前端浏览器被执行。

3)存储式XSS(持久性XSS):恶意脚本被后台存储,并后期被其它用户或管理员点击展示从而实现攻击。

例如在未做任何处理搜索网站输入,假设用户输入为:

搜索的内容是放在

中的,此时发送至服务器的数据将变成:

网站将会呈现为:

防御方法:

1). 不要信任任何用户输入,对输入的具体特殊字符,长度,类型等的数据进行过滤处理,使用输入白名单控制。可在Filter处统一对前端输入的字符进行转义过滤处理。

2). 为cookie设置httponly属性,避免攻击者通过document.cookie 盗取合法用户的cookie;

4、跨站点请求伪造(CSRF)

定义:

CSRF(Cross-siterequest forgery)跨站请求伪造,也被称为“One Click Attack”或者Session Riding,通常缩写为CSRF或者XSRF,是一种对网站的恶意利用。尽管听起来像跨站脚本(XSS),但它与XSS非常不同,XSS是由于放任来自浏览器的输入任意执行导致了,而CSRF则是因为过分信任用户,放任来自通过身份验证的所谓合法用户的请求执行网站的某个特定功能而进行的攻击。与XSS攻击相比,CSRF攻击往往不大流行(因此对其进行防范的资源也相当稀少)和难以防范,CSRF比XSS更具危险性。

防御建议:

1)验证 HTTP Referer 字段

根据 HTTP 协议,在HTTP 头中有一个字段叫 Referer,它记录了该HTTP 请求的来源地址。在通常情况下,访问一个安全受限页面的请求来自于同一个网站,比如需要访问http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory,用户必须先登陆 bank.example,然后通过点击页面上的按钮来触发转账事件。这时,该转帐请求的Referer 值就会是转账按钮所在的页面的 URL,通常是以bank.example 域名开头的地址。而如果黑客要对银行网站实施 CSRF 攻击,他只能在他自己的网站构造请求,当用户通过黑客的网站发送请求到银行时,该请求的 Referer 是指向黑客自己的网站。因此,要防御 CSRF 攻击,银行网站只需要对于每一个转账请求验证其 Referer 值,如果是以 bank.example 开头的域名,则说明该请求是来自银行网站自己的请求,是合法的。如果 Referer 是其他网站的话,则有可能是黑客的 CSRF 攻击,拒绝该请求。

2)在请求地址中添加 token 并验证 CSRF 攻击之所以能够成功,是因为黑客可以完全伪造用户的请求,该请求中所有的用户验证信息都是存在于 cookie 中,因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的cookie 来通过安全验证。要抵御 CSRF,关键在于在请求中放入黑客所不能伪造的信息,并且该信息不存在于 cookie 之中。可以在 HTTP 请求中以参数的形式加入一个随机产生的 token,并在服务器端建立一个拦截器来验证这个 token,如果请求中没有 token 或者 token 内容不正确,则认为可能是 CSRF 攻击而拒绝该请求。

3)在 HTTP 头中自定义属性并验证 这种方法也是使用 token 并进行验证,和上一种方法不同的是,这里并不是把 token 以参数的形式置于 HTTP 请求之中,而是把它放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 这个类,可以一次性给所有该类请求加上 csrftoken这个 HTTP 头属性,并把 token 值放入其中。这样解决了上种方法在请求中加入 token 的不便,同时,通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏,也不用担心 token 会透过 Referer 泄露到其他网站中去。

本期先给大家分享这几个常见代码漏洞,你get到了吗?

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180509G17ACL00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券