WEB应用安全问题常见种类.pdfVIP

1. SQL注入； 2. 跨站脚本编制； 3. 跨站请求伪造； 4. 链接注入及通过框架钓鱼； 5. 解密的登录请求； SQL注入 Web应用通常在后端使用数据库，数据查询、更新等功能是通过 SQL语句操作数据库 完成的。应用程序通常会通过HTTP请求获取用户输入将它并入 SQL语句中，然后发送到 后端数据库，接着应用程序便处理返回结果，有时会向用户显示结果。如果应用程序对用户 输入的数据处理不够小心，恶意用户便可以利用这种操作方式达到攻击。在此情况下，攻击 者可以输入特定的数据，当该数据并入 SQL语句中时，就将 SQL原始语法构造得面目全非。 例如MIS系统典型情况，应用程序使用用户输入的用户名和密码来查询用户账户的数据库 表，以认证用户，而攻击者能够将恶意数据注入查询的用户名部分（和/或密码部分），查 询便可能更改成完全不同的数据查询，也可能是修改数据的查询或在数据库服务器上运行 Shell命令的查询。 一般开发人员认为，降低 SQL注入攻击风险的一般方式是禁止详细的 SQL错误消息， “因为攻击者通常是便利用这些消息找出容易遭受 SQL ”注入 的脚本或页面的，但是这个解 “决方案可以利用称为 SQL ”盲注 的技术来略过，攻击者不需要依赖被注入 SQL语句的执行 错误信息便能找出容易那些易受攻击的脚本或页面。 本质上讲，避免 SQL注入的根本解决方法是对用户输入数据进行模式过滤，这些过滤应 包括： 1．使用 SQL条件参数化来避免直接利用用户输入作为 SQL语句条件部分（WHERE 子句），来拼接 SQL语句所可能带来的语义串改；需要注意的是，不是所有 SQL注 入（及盲注）都是能够通过这种方式来避免的，因为不是所有业务的用户输入数据 都只作用到 SQL语句的条件部分，在本次涉及的 7个应用系统中，存在的很多 SQL 注入缺陷都是发生的不能使用 SQL条件参数化而使用 SQL拼串的业务用例中； 2．转义 SQL保留字符。对用户输入数据中存在的 SQL保留字符进行转义，最基本的 如单引号替换为连续两个单引号。在做此类转义替换时，必须同时考虑避免转义替 换后带来的二级注入问题，这包括截断。因此对于只作用到 SQL语句的条件部分的 用户输入，应优先使用上述 SQL条件参数化来避免注入攻击； 3．避免过于详细的 SQL执行异常提示信息。这种考虑的目的显而易见，通过避免 SQL 执行异常信息暴露给最终用户，可以有效避免攻击者通过应用返回的错误提示信息 来获得用于执行更精确的攻击所需要的信息。这种方式仅能够为 SQL注入设置障碍。 下面列举准金融系统应用安全测试所发现的典型 SQL注入缺陷，深入的说明分析需要从 开发角度另行展开，暂时资源有限。 POST /feeManage/transferpayaccept.do? method=doTransferPayPayFee=0.00ServiceKind=9TransId=350IfEntrust=0 EntrustAccountFeeId=0AccountIdfTrans=1ServiceId858Note=UnitFee=0.00PresentFee=0.00 HTTP/1.0 Cookie: JSESSIONID1=0000E8CsloTOwVI_5PyPvVOoSHA:-1; JSESSIONID3=0000vOPtHpNFLDYGuW0JnvkAF3Q:-1; JSESSIONID2=0000OaSqYf_qD2IeDdi7At6NEHj:-1; PHPSESSID=2fccd47c0d0234507adb31dcf2063879 Content-Length: 322 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave- flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/xaml+xml, application/vnd.ms-xpsdocument, application/x-ms-xbap, application/x-ms-application, */* Referer: 6:8080/feeManage/transferpayaccept.do?method=initFun Accept-Language: zh-cn Content-Type: application/x-www-form-urlencoded User-Agent: Mozilla