如何进行Web渗透测试

Web渗透测试可以从以下几个方面考虑：
　　1.SQL Injection(SQL注入)
　　(1)如何进行SQL注入测试?
　　首先找到带有参数传递的URL页面,如 搜索页面,登录页面,提交评论页面等等.
　　注1:对 于未明显标识在URL中传递参数的,可以通过查看HTML源代码中的"FORM"标签来辨别是否还有参数传递.在

和的标签中间的每一个参数传递都有可能被利用.
　　
　　

　　
　　
　　 Gamefinder
　　

　　
　　注 2:当你找不到有输入行为的页面时,可以尝试找一些带有某些参数的特殊的URL,如 HTTP://DOMAIN/INDEX.ASP?ID=10
　　其 次,在URL参数或表单中加入某些特殊的SQL语句或SQL片断,如在登录页面的URL中输入 HTTP://DOMAIN /INDEX.ASP?USERNAME='HI' OR 1=1
　　注1：根据实际情况,SQL注入请求可以使用以下语句:
　　' or 1=1- -
　　" or 1=1- -
　　or 1=1- -
　　' or 'a'='a
　　" or "a"="a
　　') or ('a'='a
　　注2：为什么是OR， 以及',――是特殊的字符呢？
　　例子：在登录时进行身份验证时，通常使用如下语句来进行验证：sql=select * from user where username='username' and pwd='password'
　　如 输入 http://duck/index.asp?username=admin' or 1='1&pwd=11，SQL语句会变成以下：sql=select * from user where username='admin' or 1='1' and password='11'
　　' 与admin前面的'组成了一个查询条件,即username='admin',接下来的语句将按下一个查询条件来执行.
　　接 下来是OR查询条件,OR是一个逻辑运 算符，在判断多个条件的时候，只要一个成立，则等式就成立，后面的AND就不再时行判断了，也就是 说我们绕过了密码验证，我们只用用户名就可以登录.
　　如 输入 http://duck/index.asp?username=admin'--&pwd=11，SQL语 句会变成以下sql=select * from user where name='admin' --' and pasword='11',
　　'与admin前面的'组成了一个查 询条件,即username='admin',接下来的语句将按下一个查询条件来执行
　　接下来是"--"查询条件,“--”是忽略或注释,上 述通过连接符注释掉后面的密码验证(注:对ACCESS数据库无 效).
　　最后,验证是否能入侵成功或是出错的信息是否包含关于数据库服务器 的相关信息;如果 能说明存在SQL安 全漏洞.
　　试想,如果网站存在SQL注入的危险,对于有经验的恶意用户还可能猜出数据库表和表结构,并对数据库表进行增删改的操 作,这样造成的后果是非常严重的.
　　(2)如何预防SQL注入?
　　从应用程序的角度来讲,我们要做以下三项工作:
　　转义敏感字符及字符串(SQL的敏感字符包括“exec”,”xp_”,”sp_”,”declare”,”Union”,”cmd”,”+”,”//”,”..”,”;”,”‘”,”--”,”%”,”0x”,”><=!-*/()|”,和”空格”).
　屏蔽出错信息：阻止攻击者知道攻击的结果
　　在服务端正式处理之前提交数据的合法性(合法性检查主要包括三 项:数据类型,数据长度,敏感字符的校验)进行检查等。最根本的解决手段,在确认客 户端的输入合法之前,服务端拒绝进行关键性的处理操作.
　　从测试人员的角度来讲,在程序开发前(即需求阶段),我们就应该有意识的将安全性检查应用到需求测试中,例如对一个表单需求进行检查时,我们一般检验以下几项安全性问题:
　　需求中应说明表单中某一FIELD的类型,长度,以及取值范围(主要作用就是禁止输入敏感字符)
　　需求中应说明如果超出表单规定的类型,长度,以及取值范围的,应用程序应给出不包含任何代码或数据库信息的错误提示.
　　当然在执行测试的过程中,我们也需求对上述两项内容进行测试.
　　2.Cross-site scritping(XSS):(跨站点脚本攻击)
　　(1)如何进行XSS测试?
　　é¦å,æ¾å°å¸¦æåæ°ä¼ éçURL,å¦ ç»å½é¡µé¢,æ索页é¢,æ交è¯è®º,å表çè¨ é¡µé¢ç­ç­ã
ããå¶æ¬¡,å¨é¡µé¢åæ°ä¸­è¾å¥å¦ä¸è¯­å¥(å¦:JavascrÄ«pt,VB scrÄ«pt, HTML,ActiveX, Flash)æ¥è¿è¡æµè¯ï¼
ããalert(document.cookie)Ä«pt>
ããæå,å½ç¨æ·æµè§ æ¶ä¾¿ä¼å¼¹åºä¸ä¸ªè­¦åæ¡ï¼å容æ¾ç¤ºçæ¯æµè§èå½åçcookie串,è¿å°±è¯´æ该ç½ç«å­å¨XSSæ¼æ´ã
ããè¯æ³å¦ææ们注å¥çä¸æ¯ä»¥ä¸è¿ä¸ªç®åçæµè¯ä»£ç ï¼èæ¯ä¸æ®µç»å¸¸ç²¾å¿è®¾è®¡çæ¶æèæ¬ï¼å½ç¨æ·æµè§æ­¤å¸æ¶ï¼cookieä¿¡æ¯å°±å¯è½æåç被 æ»å»èè·åãæ­¤æ¶æµè§èçå¸å·å°±å¾å®¹æ被æ»å»èææ§äºã
ãã(2)å¦ä½é¢é²XSSæ¼æ´?
ããä»åºç¨ç¨åºçè§åº¦æ¥è®²,è¦è¿è¡ä»¥ä¸å é¡¹é¢é²:
ãã对JavascrÄ«pt,VB scrÄ«pt, HTML,ActiveX, Flashç­ è¯­å¥æèæ¬è¿è¡è½¬ä¹.
ããå¨ æå¡ç«¯æ­£å¼å¤çä¹åæ交æ°æ®çåæ³æ§(åæ³æ§æ£æ¥ä¸»è¦åæ¬ä¸é¡¹:æ°æ®ç±»å,æ°æ®é¿åº¦,ææå­ç¬¦çæ ¡éª)è¿è¡æ£æ¥ç­ãææ ¹æ¬ç解å³æ段,å¨ç¡®è®¤å®¢æ·ç«¯çè¾å¥åæ³ä¹å,æå¡ç«¯ æç»è¿è¡å³é®æ§çå¤çæä½.
ããä»æµè¯äººåçè§åº¦æ¥è®²,è¦ä»éæ±æ£æ¥åæ§è¡æµè¯è¿ç¨ä¸¤ä¸ªé¶æ®µæ¥å®æXSSæ£æ¥:
ããå¨éæ±æ£æ¥è¿ç¨ä¸­å¯¹åè¾å¥é¡¹æè¾åºé¡¹è¿è¡ç±»åãé¿åº¦ä»¥åå å¼èå´è¿è¡éªè¯ï¼çééªè¯æ¯å¦å¯¹HTMLæèæ¬ä»£ç è¿è¡äºè½¬ä¹ã
ããæ§è¡æµè¯è¿ç¨ä¸­ä¹åºå¯¹ä¸è¿°é¡¹è¿è¡æ£æ¥ã
ãã3.CSRF:(è·¨ç«ç¹ä¼ªé è¯·æ±)
ããCSRF尽管å¬èµ·æ¥åè·¨ç«èæ¬ï¼XSSï¼ï¼ä½å®ä¸XSSé常ä¸åï¼å¹¶ä¸æ»å»æ¹å¼å ä¹ç¸å·¦ã
ããXSSæ¯å©ç¨ç«ç¹åçä¿¡ä»»ç¨æ·ï¼èCSRFåéè¿ä¼ªè£æ¥èªåä¿¡ä»»ç¨æ·ç请æ±æ¥å©ç¨åä¿¡ä»»çç½ç«ã
ããXSSä¹å¥½ï¼CSRFä¹å¥½ï¼å®çç®çå¨äºçªåç¨æ·çä¿¡æ¯ï¼å¦SESSION å COOKIESï¼
ãã(1)å¦ä½è¿è¡CSRFæµè¯ï¼
ããç®å主è¦éè¿å®å¨æ§æµè¯å·¥å·æ¥è¿è¡æ£æ¥ã
ãã(2)å¦ä½é¢é²CSRFæ¼æ´ï¼
ããè¿ä¸ªæ们å¨è¿å°±ä¸ç»è°äº
ãã4.Email Header Injection(é®ä»¶æ å¤´æ³¨å¥)
ããEmail Header Injectionï¼å¦æ表åç¨äºåéemail,表å中å¯è½åæ¬âsubjectâè¾å¥é¡¹ï¼é®ä»¶æ é¢ï¼ï¼æ们è¦éªè¯subject中åºè½escapeæânâæ è¯ã
ããå ä¸ºânâæ¯æ°è¡ï¼å¦æå¨subject中è¾å¥âhelloncc:[email protected]âï¼å¯è½ä¼å½¢æ以ä¸
ããSubject: hello
ããcc: [email protected]
ãã如果允许用户使用这样的subject，那他可能会给利用这个缺陷通过我们的平台给其它用 户发送垃圾邮件。
　　5.Directory Traversal(目录遍历)
　　（1）如何进行目录遍历测试？
　　目录遍历产生的原因是：程序中没有过滤用户输入的“../”和“./”之类的目录跳转符,导致恶意用户可以通过提交目录跳转来遍历服务器上的任意文件。
　　测试方法：在URL中输入一定数量的“../”和“./”，验证系统是否ESCAPE掉了这些目录跳转符。
　　（2）如何预防目录遍历？
　　限制Web应用在服务器上的运行
　　进 行严格的输入验证，控制用户输入非法路径
　　6.exposed error messages(错误信息)
　　（1）如何进行测试？
　　首 先找到一些错误页面，比如404,或500页面。
　　验证在调试未开通过的情况下，是否给出了友好的错误提示信息比如“你访问的页面不存 在”等，而并非曝露一些程序代码。
　　（2）如何预防？
　　测试人员在进行需求检查时，应该对出错信息 进行详细查，比如是否给出了出错信息，是否给出了正确的出错信息。

最新内容请见作者的GitHub页：http://qaseven.github.io/