案例
HTTP://xxx.xxx.xxx/abc.asp?p=YY
①HTTP://xxx.xxx.xxx/abc.asp?p=YY’(附加一个单引号), abc.asp运行非常,表示没有对分外字符进行转义或过滤
②HTTP://xxx.xxx.xxx/abc.asp?p=YY and 1=1, abc.asp运行正常,而且与HTTP://xxx.xxx.xxx/abc.asp?p=YY运行结果相同;
③HTTP://xxx.xxx.xxx/abc.asp?p=YY and 1=2, abc.asp运行非常;
如果以上三步全面知足,abc.asp中一定存在SQL注入漏洞。
攻击步骤
1、 创造SQL注入位置;
2、 判断后台数据库类型;
3、 确定XP_CMDSHELL可实行情形
4、 创造WEB虚拟目录
5、 上传木马;
6、 得到管理员权限;
详细见:http://www.cnblogs.com/tanshuicai/archive/2010/02/03/1664900.html
常见的不屈安写法:
Statement s = connection.createStatement();
ResultSet rs = s.executeQuery(\"大众SELECT email FROM member WHERE name = \公众 + formField);
安全写法
PreparedStatement ps = connection.prepareStatement(
\"大众SELECT email FROM member WHERE name = ?\公众);
ps.setString(1, formField);
ResultSet rs = ps.executeQuery();
如何防御?
转义?过滤?
避开过滤方法
1、大小写变种
若小写被过滤,则变成大写连续实行
http://bbs.ichunqiu.com/data/attachment/forum/201608/21/134905u36phck612j6kw3j.gif?_=5793686
2、URL编码
双url编码可以绕过过滤
http://bbs.ichunqiu.com/data/attachment/forum/201608/21/143646fnygion74g9c8idi.gif?_=5793686
3、SQL注释
很多开拓职员认为,将输入限定为单个就可以限定SQL注入攻击,以是他们每每就只是阻挡各种空缺符,但是内联注释不该用空格就可以布局任意繁芜的SQL语句。
http://bbs.ichunqiu.com/data/attachment/forum/201608/21/142321um0h0q5zefvhooqk.gif?_=5793686
防御
输入验证是指要验证所有运用程序吸收到的输入是否合法。
有两中不同类型的输入验证方法:白名单和黑名单验证
白名单验证:比如id值,那么我们判断它是否为数字。
黑名单验证:利用正则表达式禁止利用某些字符和字符串
该当只管即便利用白名单,对付无法利用白名单的,利用黑名单供应局部限定。
跨站脚本(XSS)跨站脚本(cross site script)为了避免与样式css稠浊,以是简称为XSS。
什么是XSS?
XSS是指攻击者利用网站没有对用户提交数据进行转义处理或者过滤不敷的缺陷,进而添加一些代码,嵌入到web页面中去。使别的用户访问都会实行相应的嵌入代码。从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击办法。
反射型xss攻击
一样平常会放在要求或者跳转的链接中,一次性造成攻击。,称之为反射性XSS攻击
例:页面搜索框输入\"大众/><script>alert(\"大众这是一个反射型xss攻击\"大众)</script>后点击搜索,会提示提示框
存储式XSS攻击
一样平常是在提交表单式的要求中,注入XSS,存入做事器中,达到攻击打开的用户,影响所有看到的人。
例:新建用户,描述中输入\"大众/><script>alert(\"大众这是一个存储型xss攻击\"大众)</script>
保存后,后面的用户打开用户管理页面,查看到刚添加的用户所在页,都会弹出提示框
防御
1. 前端在显示做事端数据时候,不仅是标签内容须要过滤、转义,属性值也可能须要。
1) 将主要的cookie标记为http only, 这样的话Javascript 中的document.cookie语句就不能获取到cookie了。
2) 表单数据规定值的类型,例如:年事应为只能为int、name只能为字母数字组合。。。
3) 对数据进行Html Encode 处理
4) 过滤或移除分外的Html标签,例如: <script>, <iframe> , < for <, > for >, " for
5) 过滤JavaScript 事宜的标签。例如 \"大众onclick=\"大众, \"大众onfocus\"大众 等等。
2. 后端吸收要求时,验证要求是否为攻击要求,攻击则屏蔽。
【特殊把稳】
在有些运用中是许可html标签涌现的,如输出须要html代码、javascript代码拼接、或者此表单直接许可利用等等,须要差异处理。
跨站要求假造(CSRF)CSRF(Cross-site request forgery), 便是攻击者盗用你的身份,以你的名义发送恶意要求。
攻击事理
如图所示,个中Web A为存在CSRF漏洞的网站,Web B为攻击者构建的恶意网站,User C为Web A网站的合法用户。
1、用户C打开浏览器,访问网站A,输入用户名和密码要求登录网站A;
2、在用户信息通过验证后,网站A产生Cookie信息并返回给浏览器,此时用户登录网站A成功,可以正常发送要求到网站A;
3、用户未退出网站A之前,在同一浏览器中,打开一个TAB页访问网站B;
4、网站B吸收到用户要求后,返回一些攻击性代码,并发出一个要求哀求访问站点A;
5、浏览器在吸收到这些攻击性代码后,根据网站B的要求,在用户不知情的情形下携带Cookie信息,向网站A发出要求。网站A并不知道该要求实在是由B发起的,以是会根据用户C的Cookie信息以C的权限处理该要求,导致来自网站B的恶意代码被实行。
CSRF攻击是源于WEB的隐式身份验证机制!
WEB的身份验证机制虽然可以担保一个要求是来自于某个用户的浏览器,但却无法担保该要求是用户批准发送的!
案例
银行网站A,它以GET要求来完成银行转账的操作,如:
http://www.mybank.com/Transfer.php?toBankId=11&money=1000
危险网站B,它里面有一段HTML的代码如下:
<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>
首先,你登录了银行网站A,然后访问危险网站B,这时你会创造你的银行账户少了1000块......
为什么会这样呢?缘故原由是银行网站A利用GET要求更新资源。在访问危险网站B的之前,你已经登录了银行网站A,而B中的<img>以GET的办法要求第三方资源(这里的第三方便是指银行网站了,原来这是一个合法的要求,但这里被不法分子利用了),以是你的浏览器会带上你的银行网站A的Cookie发出Get要求,去获取资源“http://www.mybank.com/Transfer.php?toBankId=11&money=1000”,结果银行网站做事器收到要求后,认为这是一个更新资源操作(转账操作),以是就急速进行转账操作......
防御
优先考虑的便是利用已有的CSRF防护方案。许多框架,如Spring, Play, Django以及AngularJS,都内嵌了CSRF防护,一些web开拓措辞如.Net也供应了类似的防护,OWASP CSRF Guard对Java运用供应了CSRF防护。否则须要在每个HTTP要求中添加一个不可预测的令牌,这种令牌至少该当对每一个用户会话来说是唯一的。
1、 做事器端验证HTTP Referer字段
根据HTTP协议,在HTTP头中有一个字段叫Referer,记录了该HTTP要求的来源地址。访问一个安全受限页面的要求必须来自于同一个网站。比如某银行的转账是通过用户访问http://bank.test/test?page=10&userID=101&money=10000页面完成,用户必须先登录bank.test,然后通过点击页面上的按钮来触发转账事宜。当用户提交要求时,该转账要求的Referer值就会是转账按钮所在页面的URL(本例中,常日因此bank. test域名开头的地址)。而如果攻击者要对银行网站履行CSRF攻击,他只能在自己的网站布局要求,当用户通过攻击者的网站发送要求到银行时,该要求的Referer是指向攻击者的网站。因此,要防御CSRF攻击,银行网站只须要对付每一个转账要求验证其Referer值,如果因此bank. test开头的域名,则解释该要求是来自银行网站自己的要求,是合法的。如果Referer是其他网站的话,就有可能是CSRF攻击,则谢绝该要求。
2、 在要求地址中添加token并验证或验证码
CSRF攻击之以是能够成功,是由于攻击者可以假造用户的要求,该要求中所有的用户验证信息都存在于Cookie中,因此攻击者可以在不知道这些验证信息的情形下直策应用用户自己的Cookie来通过安全验证。由此可知,抵御CSRF攻击的关键在于:在要求中放入攻击者所不能假造的信息,并且该信息不存在于Cookie之中。鉴于此,系统开拓者可以在HTTP要求中以参数的形式加入一个随机产生的token,并在做事器端建立一个拦截器来验证这个token,如果要求中没有token或者token内容禁绝确,则认为可能是CSRF攻击而谢绝该要求。
3、 考虑对所有cookie利用”SameSite”标签,该标签逐渐被各种浏览器所支持。
防止 CSRF 攻击的办法已经有 CSRF token 校验和 Referer 要求头校验。为了从源头上办理这个问题,Google 起草了 一份草案 来改进 HTTP 协议,那便是为 Set-Cookie 相应头新增 SameSite 属性,它用来标明这个 cookie 是个“同站 cookie”,同站 cookie 只能作为第一方 cookie,不能作为第三方 cookie。
参考:http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html
失落效的认证和会话管理身份认证
最常见的是登录功能,每每是提交用户名和密码,在安全性哀求更高的情形下,有防止密码暴力破解的验证码,基于客户真个证书,物理口令卡等。
会话管理
HTTP本身是无状态的,利用会话管理机制来实现连接识别。
身份认证的结果每每是得到一个令牌,常日放在cookie中,如jsessionid。之后对用户身份的识别根据这个授权的令牌进行识别,而不须要每次都要登录。
失落效的认证和会话管理
开拓者常日会建立自定义的认证和会话管理方案。但要精确实现这些方案却很难,结果这些自定义的方案每每在如下方面存在漏洞:退出、密码管理、超时、记住我、秘密问题、帐户更新等等
案例
1、机票预订运用程序支持URL重写,把会话ID放在URL里:
http://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?dest=Hawaii
该网站一个经由认证的用户希望让他朋友知道这个机票打折信息。他将上面链接通过邮件发给他朋友们,并不知道自己已经泄露了自己的会话ID。当他的朋友们利用上面的链接时,他们将会利用他的会话和信用卡。
2、运用程序超时设置不当。用户利用公共打算机访问网站。离开时,该用户没有点击退出,而是直接关闭浏览器。攻击者在一个小时后能利用相同浏览器通过身份认证。盐
3、攻击者进入系统的数据库。存储在数据库中的用户密码没有被哈希和加盐, 所有用户的密码都被攻击者得到。
如何验证程序是否存在失落效的认证和会话管理?
最须要要保护的数据是认证凭据(credentials) 和会话ID。
1、当存储认证凭据时,是否总是利用hashing或加密保护吗?
2、认证凭据是否可预测,或者能够通过薄弱的的帐户管理功能(例如账户创建、密码修正、密码规复, 弱会话ID)重写?
3、会话ID是否暴露在URL里(例如, URL重写) ?
4、会话ID是否随意马虎受到会话固定(session fixation) 的攻击?
5、会话ID会超时吗? 用户能退出吗?
6、成功注册后,会话ID会轮转吗?
7、密码、会话ID和其他认证凭据是否只通过TLS连接传输?
防御
1、区分公共区域和受限区域
站点的公共区域许可任何用户进行匿名访问。受限区域只能接管特定用户的访问,而且用户必须通过站点的身份验证。
2、对终极用户帐户利用帐户锁定策略
当终极用户帐户几次登录考试测验失落败后,可以禁用该帐户或将事宜写入日志。
3、支持密码有效期
密码不应固定不变,而应作为常规密码掩护的一部分,通过设置密码有效期对密码进行变动。在运用程序设计阶段,该当考虑供应这种类型的功能。
4、能够禁用或锁定帐户
如果在系统受到威胁时使凭据失落效或禁用帐户,则可以避免遭受进一步的攻击。
5、不要在用户存储中存储密码
如果必须验证密码,则没有必要实际存储密码。相反,可以存储一个单向哈希值,然后利用用户所供应的密码重新打算哈希值。为减少对用户存储的词典攻击威胁,可以利用强密码,并将随机 salt 值与该密码结合利用。
6、哀求利用强密码
哀求输入至少 8 位字符,个中要包含大写字母、小写字母、数字和分外字符。无论是利用平台履行密码验证还是开拓自己的验证策略,此步骤在对付粗暴攻击时都是必需的。在粗暴攻击中,攻击者试图通过系统的试错法来破解密码。利用常规表达式帮忙强密码验证。
7、不要在网络上以纯文本形式发送密码
以纯文本形式在网络上发送的密码随意马虎被窃听。应加密传输。
8、保护身份验证 Cookie
身份验证 cookie 被盗取意味着登录被盗取。可以通过加密和安全的通信通道来保护验证票证。其余,还应限定验证票证的有效期,以防止因重复攻击导致的欺骗威胁。
不要通过 HTTP 连接通报身份验证 cookie。在授权 cookie 内设置安全的 cookie 属性,以便指示浏览器只通过 HTTPS 连接向做事器传回 cookie。
9、对身份验证 cookie 的内容进行加密
纵然利用 SSL,也要对 cookie 内容进行加密。如果攻击者试取利用XSS攻击盗取 cookie,这种方法可以防止攻击者查看和修正该 cookie。在这种情形下,攻击者仍旧可以利用 cookie 访问运用程序,但只有当 cookie 有效时,才能访问成功。
10、限定会话寿命
缩短会话寿命可以降落会话挟制和重复攻击的风险。会话寿命越短,攻击者捕获会话 cookie 并利用它访问运用程序的韶光越有限。
失落效的访问掌握当天生web页面时,数据、运用程序和APIs常常利用工具的实名或关键字。功能、URLs和函数名称常常随意马虎被猜解。而运用程序和APIs并不总是验证用户对目标资源的访问授权,如普通用户可以访问管理员的页面,这就导致了访问掌握失落效。测试者能轻易操作参数值以检测该漏洞。代码剖析能很快显示运用程序是否进行了精确的权限验证。
攻击
猜一些页面的url,进行攻击。
案例
管理员页面并没有菜单管理的权限,但是却可以在浏览器中输入菜单管理的url:menu来访问菜单管理页面
防御
1、检讨访问。任何来自不可信源的直接工具引用都必须通过访问掌握检测,确保该用户对要求的工具有访问权限。
2、利用基于用户或者会话的间接工具引用。这样能防止攻击者直接攻击未授权资源。例如,一个下拉列表包含6个授权给当前用户的资源,它可以利用数字1-6来指示哪个是用户选择的值,而不是利用资源的数据库关键字来表示。OWASP的ESAPI包含了两种序列和随机访问引用映射,开拓职员可以用来肃清直接工具引用。
3、自动化验证。利用自动化验证精确的授权支配。这是常日做法。
安全配置缺点没有精确的安全配置,导致外部的匿名攻击者和拥有帐户的内部用户都可能会试图毁坏系统
攻击
攻击者访问默认账户,无效页面,没打补丁的漏洞,未受保护的文件及文件夹等,以得到未授权的访问或对运用系统进行理解和剖析。
案例
1、做事器管理员掌握台自动安装后没有被删除。而默认帐户也没有被改变。攻击者在你的做事器上创造了标准的管理员页面,通过默认密码登录,从而接管了你的做事器。
2、目录列表在你的做事器上未被禁用。攻击者创造只需列出目录,她就可以找到你做事器上的任意文件。攻击者找到并下载所有已编译的Java类,通过反编译得到了所有你的自定义代码。然后,她在你的运用程序中找到一个访问掌握的严重漏洞。
3、运用做事器配置许可堆栈跟踪信息返回给用户,这样就暴露了潜在的漏洞。如已知的有漏洞的框架版本。
4、运用做事器自带的示例运用程序没有从您的生产做事器中删除。该示例运用有已知安全漏洞,攻击者可以利用这些漏洞毁坏您的做事器。
防御
1、 配置所有的安全机制
2、 关掉所有不该用的做事和做事器上的示例运用程序
3、 设置角色帐号权限
4、 利用日志和警报
5、 所有缺点只显示友好信息,不显示任何与实际缺点干系的信息
6、 及时更新做事器补丁
敏感信息泄露攻击
通过SQL注入或命令实行或直策应用脚本进行爬虫,来得到用户的账号密码、实名信息透露、行为记录等
防御
1、预测一些威胁(比如内部攻击和外部用户),加密这些数据的存储以确保免受这些威胁。
2、对付没必要存放的、主要的敏感数据,应该尽快打消。
3、确保利用了得当的强大的标准算法和强大的密匙,并且密匙管理到位。
4、确保利用密码专用算法存储密码
5、禁用自动完成防止敏感数据网络,禁用包含敏感数据的缓存页面。
6、加密传输
7、利用安全的加密算法