作者:雨里漾_968 | 来源:互联网 | 2023-09-18 12:00
[TOC]一、实验目标理解常用网络攻击技术的基本原理。Webgoat实践下相关实验。二、预备知识SQL注入通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串,最终
- 一、实验目标
- 二、预备知识
- 三、实验内容
- 任务一:WebGoat环境搭建
- 任务二:SQL注入
- (1)String SQL injection
- (2)Numeric SQL injection
- (3)SQL query chaining
- (4)Compromising Availability
- 任务三:XSS攻击
- (1)Reflected XSS
- (2)DOM-Based XSS
- 任务四:CSRF攻击
- (1)Basic Get CSRF Exercise
- (2)Post a review on someone else’s behalf
- 四、实验思考
- (1)SQL注入攻击原理,如何防御?
- (2)XSS攻击的原理,如何防御?
- (3)CSRF攻击原理,如何防御?
- 五、实践体会
- 六、参考资料
一、实验目标
理解常用网络攻击技术的基本原理。Webgoat实践下相关实验。
二、预备知识
SQL注入
- 通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令。
- 就是利用现有应用程序,将(恶意的)SQL命令注入到后台数据库引擎执行的能力,它可以通过在Web表单中输入(恶意)SQL语句得到一个存在安全漏洞的网站上的数据库,而不是按照设计者意图去执行SQL语句。
XSS攻击
- 跨站脚本攻击(Cross Site Scripting),为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆。故将跨站脚本攻击缩写为XSS。
- XSS是一种经常出现在web应用中的计算机安全漏洞,它允许恶意web用户将代码植入到提供给其它用户使用的页面中。攻击者利用XSS漏洞旁路掉访问控制——例如同源策略(same origin policy)。这种类型的漏洞由于被骇客用来编写危害性更大的phishing攻击而变得广为人知。
CSRF攻击
- Cross Site Request Forgery跨站请求伪造
- CSRF就是冒名登录。跨站请求伪造的核心本质是窃取用户的Session,或者说COOKIE,因为目前主流情况Session都是存在COOKIE中。攻击者并不关心被害者具体帐号和密码,因为一旦用户进行了登录,Session就是用户的唯一凭证。只要攻击者能够得到Session,就可以伪装成被害者进入服务器。
- 主要是当访问网站A时输入用户名和密码,在通过验证后,网站A产生COOKIE信息并返回,此时登录网站A成功,可正常发送请求到网站A。在未退出网站A前,若访问另一个网站B,网站B可返回一些攻击性代码并请求访问网站A;因此在网站B的请求下,向网站A发出请求。但网站A不知道该请求恶意的,因此还是会执行该恶意代码。
三、实验内容
任务一:WebGoat环境搭建
- WebGoat是OWASP组织研制出的用于进行web漏洞实验的应用平台,用来说明web应用中存在的安全漏洞。其运行在带有java虚拟机的平台之上,并提供了一系列web安全学习的教程,来指导用户利用这些漏洞进行攻击。
- WebGoat运行在带有java虚拟机的平台之上,目前提供的训练课程有很多,包含了XSS、线程安全、SQL注入、访问控制、隐藏字段、COOKIE等。
- 下载jar包:webgoat-server-8.0.0.M26.jar
- WebGoat默认使用8080端口,所以开启前先用
netstat -tupln | grep 8080
查看端口是否被占用,如果被占用,用kill 进程号
终止占用8080端口的进程。
- 因为WebGoat运行java平台之上,所以使用
java -version
查看jdk版本
java -jar webgoat-server-8.0.0.M26.jar
加载jar包
- 浏览器中输入
http://127.0.0.1:8080/WebGoat
打开WebGoat注册界面,先注册后登录即可。
任务二:SQL注入
(1)String SQL injection
题目1
"SELECT * FROM user_data WHERE first_name = ‘John‘ AND last_name = ‘" + lastName + "‘";
,输入是lastName。
要求1
在不需要知道任何用户名的情况下,得到整张表的内容。
分析1
- 上述查询语句简化为
SELECT * FROM user_data WHERE first_name = ‘John‘ AND last_name = ‘
+ 输入
+ ‘;
- AND优先于OR运算,所以前面部分不论是什么,最终都是一个0/1,只需要OR上一个true,最终就是true
- 输入部分填写的内容只要最后是类似
OR true
即可。但是,注意到输入的前面有个‘
后面也有一个‘
,所以得到最终的输入为:(...)‘ OR ‘1‘=‘1
题目2
"SELECT * FROM employees WHERE last_name = ‘" + name + "‘ AND auth_tan = ‘" + auth_tan + "‘;
,输入是name和auth_tan。
要求2
在不需要知道任何用户名的情况下,得到整张表的内容。
分析2
- 上述查询语句简化为
SELECT * FROM employees WHERE last_name = ‘
+ 输入name
+ ‘AND auth_tan =‘
+ 输入auth_tan‘;
- 看到AND,我首先想到的是能不能将其通过注释消除掉,那么通过
name = ‘ or true
就轻松破了这个题目。
(2)Numeric SQL injection
题目
"SELECT * FROM user_data WHERE login_count = " + Login_Count + " AND userid = " + User_ID;
输入是Login_Count和User_ID。
要求
Login_Count必须是数字,且通过这两个输入,得到整张表的内容。
分析
- 上述查询语句简化为
SELECT * FROM user_data WHERE login_count =
+ 输入Login_Count
+ AND userid =
+ 输入User_ID;
,即在表中查询login_count = 输入1 AND userid =输入2
- 看到AND,我首先想到的是能不能将其通过注释消除掉,但是这里要求Login_Count必须是数字,那么通过
Login_Count=1 or true --
这种方式很明显就无法实现。
- 那么就只能userid入手了,通过
userid = 1 or true
这个Solution就能破了这个题目。
(3)SQL query chaining
题目
"SELECT * FROM employees WHERE last_name = ‘" + name + "‘ AND auth_tan = ‘" + auth_tan + "‘;
- 已知Tobi和Bob工资比你高,通过修改你的工资,使得你的工资是最高的。
- 你的名字是John Smith,你现在的TAN是3SL99A。
- 输入是Employee Name 和 Authentication TAN。
要求
只知道自己的Name和TAN,通过修改自己的工资,使得表中自己的工资最高。
分析
- 这题与上面的题目有所不同,这道题需要对表中内容进行修改,所以需要用到修改语句
update employees set salary=1000000 where last_name=‘Smith‘;
,这里随便取了一个数值作为自己工资,觉得应该是够了。
- 每句SQL都是以
;
分号作为结束的标志,所以我们应该先使用‘;
来结束原本的SQL语句,然后接着上面的修改语句对表中内容进行修改,最后使用--
将后面没必要的内容注释掉。
- 最终SQL语句为
SELECT * FROM employees WHERE last_name = ‘‘; update employees set salary=1000000 where last_name=‘Smith‘;
(4)Compromising Availability
题目
- 输入为:Action contains
- 通过输入的内容,查询access_log表中与其对应的部分,将其删除。
分析
- 这道题目与上一题类似,只不过将注入的SQL修改语句改为SQL删除语句,以达到将日志中记录的相应内容删除,从而隐藏攻击者的攻击行为。
- 删除语句为:
drop table access_log;
- 同样先使用
‘;
来结束原本的SQL语句,然后接着上面的删除语句对表中删除相应内容,最后使用--
注释后面内容。
任务三:XSS攻击
(1)Reflected XSS
- 确定哪个字段易受XSS的影响,验证服务器端的所有输入总是一种很好的做法。 当HTTP响应中使用未经验证的用户输入时,可能会发生XSS;
- 在反射的XSS攻击中,攻击者可以用攻击脚本制作一个URL,并将其发布到另一个网站,发送电子邮件,或者以其他方式让受害者点击它;
- 一个简单的方法来确定一个字段是否容易受到XSS攻击,就是使用alert.()或console.log()方法,用其中一个找出哪个领域是脆弱的。
题目
分析
- 当我点击Update Cart时,可以看到页面上输出,初步确认卡号字段存在xss
- 然后我直接注入
发现成功了。
(2)DOM-Based XSS
基于DOM的XSS通常可以通过查找客户端代码中的路由配置来找到。
题目1
通过检查Java脚本源代码,找到test路径。
分析1
- 没有头绪,我就随便输了个路径点提交,发现回显里有提示:
No, look at the example. Check the GoatRouter.js file. It should be pretty easy to determine.
- 于是打开调试器,查看
GoatRouter.js
,里面有一句:‘test/:param‘: ‘testRoute‘
,得到答案:start.mvc#test/
题目2
利用上一题中找到的测试路径,成功出发WebGoat中的内部函数webgoat.customjs.phoneHome()
分析2
- 题目中说让我们利用上一题中找到的测试路径。那么先尝试直接把函数贴到路径后面执行一下。
可以看到没有调用函数,而是直接回显了。
这次没有回显,说明应该是调用成功了。打开控制台,发现结果已经出来,末尾的数字就是答案。
任务四:CSRF攻击
(1)Basic Get CSRF Exercise
题目
分析1
题目要求我们换个源点击这个提交,那么就用Burp抓个包,把referer随便改一下,就得到了flag,然后把得到的flag填到下面的Confirm Flag Value中,就成功了。
分析2
- 用Burp生成一个PoC,PoC大概是验证程序的意思,在这里生成CSRF,PoC就是生成一段能点击这个链接的html代码。
- 生成html代码后,点击
Test in browser
后会生成一个网址,在连接Burp代理的情况下打开就会出现一个有按钮的页面,点击按钮跳转页面,得到flag。
(2)Post a review on someone else’s behalf
题目
下面的页面模拟评论/评论页面。 这里的区别是,您必须在其他地方启动提交,就像您可能使用CSRF攻击一样,并且类似于前面的练习。
分析
思路与上一题相似,只不过是把GET方法换成POST方法,这里就不重复叙述。
四、实验思考
(1)SQL注入攻击原理,如何防御?
原理
- SQL注入攻击指的是通过构建特殊的输入作为参数传入Web应用程序,而这些输入大都是SQL语法里的一些组合,通过执行SQL语句进而执行攻击者所要的操作。如通过在用户名、密码登输入框中输入一些‘,--,#等特殊字符,实现引号闭合、注释部分SQL语句,利用永真式实现登录、显示信息等目的。
- 总的来说,SQL注入就像是把前端输入的内容像填空一样填到后台递交给数据库的搜索语句中,凑成一个完整的SQL表达式,完成相应的任务。
防御
通过各种方式对非法输入进行检查:
- 检查变量数据类型和格式
- 对无法确定固定格式的变量,进行特殊符号过滤或转义处理
- 绑定变量,使用预编译语句
(2)XSS攻击的原理,如何防御?
原理
攻击者通过往Web页面里插入恶意html标签或者Javascript代码,并能够被浏览器成功的执行。
防御
- 在表单提交或者url参数传递前,对需要的参数进行过滤
- 检查用户输入的内容中是否有非法内容
(3)CSRF攻击原理,如何防御?
原理
攻击者借用用户的身份,向web server发送请求,因为该请求不是用户本意,所以称为“跨站请求伪造”。CSRF的攻击分为两步:
- 注入恶意URL
- 然后在该地址中写入攻击代码,利用等标签或者使用Javascript脚本
防御
- 通过referer、token或者验证码来检测用户提交
- 尽量不要在页面的链接中暴露用户隐私信息,对于用户修改删除等操作最好都使用post操作
- 避免全站通用的COOKIE,严格设置COOKIE的域
五、实践体会
本次实验相对而言比较有意思,一下子一个SQL注入就吸引了我的眼球,虽然自己写的代码中数据库平时不经常接触到,但是在这个大数据的时代,数据库安全变得尤为重要。如果信息系统的安全性不够,简简单单的一个SQL注入有可能就获得了国家机密。想想真是可怕。
六、参考资料
- WebGoat 8安装、配置、使用教程(CentOS)
- BurpSuite实战指南
- 0x63_Web_Webgoat安装.md