Exp9 Web安全基础

一、实验概述

0.WebGoat准备工作

&＃xff08;一&＃xff09;SQL注入攻击

• 1.命令注入(Command Injection)
• 2.数字型SQL注入(Numeric SQL Injection)
• 3.日志欺骗(Log Spoofing)
• 4.字符串型注入(String SQL Injection)
• 5.LAB: SQL Injection
• 6.数据库后门(Database Backdoors)
• 7.数字型盲注入(Blind Numeric SQL Injection)
• 8.字符串型盲注入(Blind String SQL Injection)

&＃xff08;二&＃xff09;XSS攻击

• 1.Phishing with XSS
• 2.Stored XSS Attacks
• 3.Reflected XSS Attacks

&＃xff08;三&＃xff09;CSRF攻击

• 1.Cross Site Request Forgery(CSRF)
• 2.CSRF Prompt By-Pass

二、实验内容

0.WebGoat准备工作

• WebGoat是OWASP组织研制出的用于进行web漏洞实验的应用平台&＃xff0c;用来说明web应用中存在的安全漏洞。其运行在带有java虚拟机的平台之上&＃xff0c;并提供了一系列web安全学习的教程&＃xff0c;来指导用户利用这些漏洞进行攻击。

• 下载jar包&＃xff1a;webgoat-container-7.0.1-war-exec.jar

• 进入该文件的目录下&＃xff0c;输入指令java -jar webgoat-container-7.0.1-war-exec.jar运行Webgoat&＃xff0c;结尾出现信息&＃xff1a;Starting ProtocolHandler ["http-bio-8080"]说明开启成功&＃xff0c;可以看到webgoat占用8080端口。注&＃xff1a;实验过程中不能关闭此终端。

• 输入指令netstat -tupln | grep 8080查看8080端口是否被占用。
  如果被占用&＃xff0c;用kill 进程号终止占用8080端口的进程。

• 在浏览器中输入http://localhost:8080/WebGoat进入WebGoat登录界面,直接用默认用户名密码登录即可。

• 左侧显示课程。

&＃xff08;一&＃xff09;SQL注入攻击

• SQL注入攻击是黑客对数据库进行攻击的常用手段之一。随着B/S模式应用开发的发展&＃xff0c;使用这种模式编写应用程序的程序员也越来越多。但是由于程序员的水平及经验也参差不齐&＃xff0c;相当大一部分程序员在编写代码的时候&＃xff0c;没有对用户输入数据的合法性进行判断&＃xff0c;使应用程序存在安全隐患。用户可以提交一段数据库查询代码&＃xff0c;根据程序返回的结果&＃xff0c;获得某些他想得知的数据&＃xff0c;这就是所谓的SQL Injection&＃xff0c;即SQL注入。

1.命令注入(Command Injection)

• 目标&＃xff1a;能够在目标主机上执行任何系统命令。
• 点击左侧栏中Injection Flaws -> Command Injection&＃xff0c;右击复选框&＃xff0c;选择Inspect Element审查网页元素对源代码进行修改&＃xff0c;点击下方标蓝的向右箭头&＃xff0c;使内容显示出来&＃xff0c;双击AccessControlMatrix.help&＃xff0c;在末尾添加"& netstat -an & ipconfig"。

• 点击上方复选框右侧的View&＃xff0c;看到网络端口使用情况和 IP 地址&＃xff0c;攻击成功。

2.数字型SQL注入(Numeric SQL Injection)

• 目标&＃xff1a;显示天气情况。

• 点击Injection Flaws->Numeric SQL Injection&＃xff0c;
  右击复选框Columbia&＃xff0c;选择Inspect Element审查网页元素对源代码value&＃61;"101"进行修改&＃xff0c;在城市编号101后面添加or 1&＃61;1。

• 点击Go&＃xff0c;攻击成功。

3.日志欺骗(Log Spoofing)

• 目标&＃xff1a;使用户名为admin的用户在日志中显示成功登录。

• 点击Injection Flaws->Log Spoofing&＃xff0c;
  在User Name中填入webgoat%0d%0aLogin Succeeded for username: xyh20165306&＃xff0c;利用回车0D%和换行符%0A让其在日志中两行显示。

• 密码为默认值&＃xff0c;点击Login&＃xff0c;可以看到webgoat在Login Fail那行显示&＃xff0c;自己添加的xyh20165306语句在下一行显示。

4.字符串型注入(String SQL Injection)

• 目标&＃xff1a;基于查询语句构造自己的SQL注入字符串&＃xff0c;将所有信用卡信息显示出来。
• 点击Injection Flaws->String SQL Injection&＃xff0c;输入查询的用户名xyh&＃39; or 1&＃61;1--
  &＃xff0c;使用&＃39;提前闭合""&＃xff0c;插入永真式1&＃61;1&＃xff0c;且--注释掉后面的内容&＃xff0c;这样就能select表里面的所有数据。

5.LAB: SQL Injection

• 目标&＃xff1a;使用SQL注入绕过认证。

• 点击Injection Flaws->LAB:SQL Injection&＃xff0c;在密码框输入&＃39; or 1&＃61;1 --&＃xff0c;登录失败&＃xff0c;会发现密码只有一部分输入&＃xff0c;说明密码长度有限制。

• 右击Password&＃xff0c;选择Inspect Element审查网页元素对可输入密码长度进行修改。

• 重新输入&＃39; or 1&＃61;1 --&＃xff0c;登录成功。

6.数据库后门(Database Backdoors)

• 数据库通常作为一个Web应用程序的后端来使用&＃xff0c;此外&＃xff0c;它也用来作为存储的媒介。它也可以被用来作为存储恶意活动的地方&＃xff0c;如触发器。

• 触发器是在数据库管理系统上调用另一个数据库操作&＃xff0c;如insert,select,update or delete。攻击者可以创建一个触发器&＃xff0c;该触发器在创建新用户时&＃xff0c;将每个新用户的Email 地址设置为攻击者的地址。

• 点击Injection Flaws -> Database Backdoors&＃xff0c;在User ID处输入101&＃xff0c;得到该用户的信息。可以发现&＃xff0c;输入的语句没有验证&＃xff0c;很容易进行 SQL 注入。

• 在User ID处输入注入语句101; update employee set salary&＃61;10000&＃xff0c;这里执行了两个语句&＃xff0c;中间需要用分号分隔。

• 在User ID处输入101;CREATE TRIGGER myBackDoor BEFORE INSERT ON employee FOR EACH ROW BEGIN UPDATE employee SET email&＃61;&＃39;john&＃64;hackme.com&＃39; WHERE userid &＃61; NEW.userid设置触发器。

7.数字型盲注入(Blind Numeric SQL Injection)

• 某些SQL注入是没有明确返回信息的&＃xff0c;只能通过条件的“真”和“假”进行判断。攻击者必须充分利用查询语句&＃xff0c;构造子查询语句。

• 服务端页面返回的信息只有两种&＃xff1a;帐号有效或无效。因此无法简单地查询到帐号的PIN 数值。尽管如此&＃xff0c;我们可以利用系统后台在用的查询语句SELECT * FROM user_data WHERE userid&＃61;accountNumber;&＃xff0c;如果该查询语句返回了帐号的信息&＃xff0c;页面将提示帐号有效&＃xff0c;否则提示无效。
• 使用AND函数&＃xff0c;我们可以添加一些额外的查询条件。如果该查询条件同样为真&＃xff0c;则返回结果应提示帐号有效&＃xff0c;否则无效。点击Injection Flaws ->Blind Numeric SQL Injection。
  • 输入101 AND 1&＃61;1&＃xff0c;两个条件都成立&＃xff0c;所以页面返回Account number is valid&＃xff1b;
  • 输入101 AND 1&＃61;2&＃xff0c;返回帐号无效。

• 现在针对查询语句的后半部分构造复杂语句。下面的语句可以告诉我们PIN数值是否大于10000&＃xff1a;
  • 输入101 AND ((SELECT pin FROM pins WHERE cc_number&＃61;&＃39;1111222233334444&＃39;) > 10000 );&＃xff0c;如果页面提示帐号有效&＃xff0c;说明PIN>10000&＃xff0c;否则 PIN<&＃61;10000。
  • 不断调整数值&＃xff0c;可以缩小判断范围&＃xff0c;并最终判断出PIN 数值的大小。最终如下语句返回帐号有效&＃xff1a;101 AND ((SELECT pin FROM pins WHERE cc_number&＃61;&＃39;1111222233334444&＃39;) &＃61; 2364 );&＃xff0c;说明2364为正确PIN值。

8.字符串型盲注入(Blind String SQL Injection)

• 目标&＃xff1a;找到pins表中cc_number字段值为4321432143214321的记录中pin字段的数值。pin字段类型为varchar。输入找到的数值&＃xff08;最终的字符串&＃xff0c;注意拼写和大写&＃xff09;并提交。

• 点击Injection Flaws ->Blind String SQL Injection&＃xff0c;输入101 AND (SUBSTRING((SELECT name FROM pins WHERE cc_number&＃61;&＃39;4321432143214321&＃39;), 1, 1) <&＃39;H&＃39; );&＃xff0c;使用SUBSTRING 方法&＃xff0c;取得pin 字段数值的第一个字母&＃xff0c;并判断其是否比字母“H”小。

• 经过多次测试&＃xff0c;比较0-9、A-Z、a-z等字符串和页面的返回数据&＃xff0c;判断出第一个字符为J。

• 同理继续判断第二个字符&＃xff0c;输入101 AND (SUBSTRING((SELECT name FROM pins WHERE cc_number&＃61;&＃39;4321432143214321&＃39;), 2, 1) <&＃39;h&＃39; );。

• 最终&＃xff0c;判断出pin字段的值为Jill&＃xff0c;提交该值。

&＃xff08;二&＃xff09;XSS攻击

1.Phishing with XSS

• 在XSS的帮助下实现钓鱼工具或向某些官方页面中增加内容。对于受害者来说很难发现该内容是否存在威胁。目标是创建一个form&＃xff0c;要求填写用户名和密码。

• 一个带用户名和密码输入框的表格如下&＃xff1a;

This feature requires account login:

• 点击XSS->Phishing with XSS&＃xff0c;搜索以上代码&＃xff0c;可以看到页面中增加了一个表单。

• 下方代码会读取我们在表单上输入的用户名和密码信息&＃xff0c;将这些信息发送给捕获这些信息的WebGoat。

• 将以上两段代码合并后&＃xff0c;进行搜索。

This feature requires account login:

• 在显示的表单中输入用户名和密码&＃xff0c;登录后WebGoat会将输入的信息捕获并反馈给我们。

2.Stored XSS Attacks

• 常见于论坛等留言、用户留言创建非法的消息内容&＃xff0c;输入一段Javascript脚本&＃xff0c;其被保存在数据库中&＃xff0c;任何用户在打开网页的时候&＃xff0c;这个脚本就会被从数据库中取出来而运行&＃xff0c;可以导致其他用户访问非预期的页面或内容。
• 点击XSS - > Stored XSS Attacks&＃xff0c;在Title中输入20165306&＃xff0c;留言板Message中输入。

• 点击Submit->标红的20165306&＃xff0c;攻击成功。

3.Reflected XSS Attacks

• XSS反射型攻击&＃xff0c;恶意代码并没有保存在目标网站&＃xff0c;通过使用攻击脚本创建一个URL&＃xff0c;并将其发布到另一个网站&＃xff0c;通过电子邮件引诱用户点击&＃xff0c;实施攻击。

• 点击XSS - > Reflected XSS Attacks&＃xff0c;在Enter your three digit access code中输入。

• 点击Purchase&＃xff0c;成功显示警告框&＃xff0c;内容为我们script脚本指定的内容。

&＃xff08;三&＃xff09;CSRF攻击

1.Cross Site Request Forgery(CSRF)

• CSRF通过伪装来自受信任用户的请求来利用受信任的网站。目标&＃xff1a;向一个新闻组发送一封邮件&＃xff0c;邮件中包含一张图片&＃xff0c;这个图像的URL指向一个恶意请求。

• 点击XSS->Cross Site Request Forgery(CSRF)&＃xff0c;
  查看下方Parameters中的scr和menu值为308和900。

• 在Message框中输入&＃xff0c;以图片的的形式将URL放进Message框&＃xff0c;这时的URL对其他用户是不可见的&＃xff0c;用户一旦点击图片&＃xff0c;就会触发一个CSRF事件。其中语句中的&transferFunds&＃61;5306即转走的受害人的金额&＃xff0c;宽高设置成1像素的目的是隐藏该图片。

• 点击Submit提交&＃xff0c;在Message List中生成以Title命名的链接。点击该链接&＃xff0c;当前页面就会下载这个消息并显示出来&＃xff0c;转走用户的5000元&＃xff0c;从而达到CSRF攻击的目的。

2.CSRF Prompt By-Pass

• 点击XSS - >CSRF Prompt By-Pass&＃xff0c;查看下方Parameters中的scr和menu值为325和900。

• 输入任意Title&＃xff0c;在Message中输入

• 点击Submit生成以Title命名的链接&＃xff0c;点击链接&＃xff0c;攻击成功。

三、回答问题

&＃xff08;1&＃xff09;SQL注入攻击原理&＃xff0c;如何防御

所谓SQL注入&＃xff0c;就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串&＃xff0c;最终达到欺骗服务器执行恶意的SQL命令。

sql注入攻击是利用是指利用设计上的漏洞&＃xff0c;在目标服务器上运行Sql语句以及进行其他方式的攻击&＃xff0c;动态生成Sql语句时没有对用户输入的数据进行验证是Sql注入攻击得逞的主要原因。

比如登录过程&＃xff0c;SQL语句一般为select id from users where username &＃61; &＃39;"&＃43;username &＃43;"&＃39; and password &＃61; &＃39;" &＃43; password &＃43;"&＃39;&＃xff0c;这里的username和password都是我们存取从web表单获得的数据。如果我们在表单中username的输入框中输入&＃39; or 1&＃61;1--&＃xff0c;此时我们所要执行的sql语句就变成了select id from users where username &＃61; &＃39;&＃39; or 1&＃61;1-- and password &＃61; &＃39;&＃39;。因为1&＃61;1是true&＃xff0c;后面 and password &＃61; &＃39;&＃39;被注释掉了&＃xff0c;所以这里完全跳过了sql验证。

以上是最经典的一种情况。但在本次实验中&＃xff0c;还涉及到了网页对输入字符长度的限制等等&＃xff0c;需要修改相应的代码。

由此可见&＃xff0c;对SQL注入攻击的防御&＃xff0c;主要有&＃xff1a;

• 关闭或删除不必要的交互式提交表单页面&＃xff1b;
• 对漏洞注入点相关代码进行代码及SQL注入关键字的过滤&＃xff0c;以规范代码安全性&＃xff1b;
• 不要在服务器端放置备份的文件以免受到感染&＃xff0c;或备份的文件含有漏洞&＃xff0c;造成切入点。

&＃xff08;2&＃xff09;XSS攻击的原理&＃xff0c;如何防御

攻击者利用网站漏洞&＃xff08;通常这些漏洞是指网站后台处理程序没有很好的对用户输入进行过滤&＃xff09;&＃xff0c;输入可以显示在页面上的、对其他用户造成影响的HTML代码&＃xff1b;由于受害者浏览器对目标服务器的信任&＃xff0c;当其访问目标服务器上被注入恶意脚本的页面后&＃xff0c;这段恶意脚本可以顺利执行&＃xff0c;实现获取用户COOKIE并可以利用用户身份进行非法操作的目的。

• 浏览器自身可以识别简单的XSS攻击字符串&＃xff0c;从而阻止简单的XSS攻击&＃xff1b;从根本上说&＃xff0c;解决办法是消除网站的XSS漏洞&＃xff0c;这就需要网站开发者运用转义安全字符等手段。

• 一个原则&＃xff1a;不相信用户输入的任何数据&＃xff01;

&＃xff08;3&＃xff09;CSRF攻击原理&＃xff0c;如何防御

CSRF 的全称是“跨站请求伪造”&＃xff0c;而 XSS 的全称是“跨站脚本”。看起来有点相似&＃xff0c;它们都是属于跨站攻击——不攻击服务器端而攻击正常访问网站的用户。CSRF 顾名思义&＃xff0c;是伪造请求&＃xff0c;冒充用户在站内的正常操作。我们知道&＃xff0c;绝大多数网站是通过 COOKIE 等方式辨识用户身份&＃xff08;包括使用服务器端 Session 的网站&＃xff0c;因为 Session ID 也是大多保存在 COOKIE 里面的&＃xff09;&＃xff0c;再予以授权的。所以要伪造用户的正常操作&＃xff0c;最好的方法是通过 XSS 或链接欺骗等途径&＃xff0c;让用户在本机&＃xff08;即拥有身份 COOKIE 的浏览器端&＃xff09;发起用户所不知道的请求。

严格意义上来说&＃xff0c;CSRF 不能分类为注入攻击&＃xff0c;因为 CSRF 的实现途径远远不止 XSS 注入这一条。通过 XSS 来实现 CSRF 易如反掌&＃xff0c;但对于设计不佳的网站&＃xff0c;一条正常的链接都能造成 CSRF。

防御的方法可从以下几个角度考虑&＃xff1a;

• 改良站内 API 的设计。对于发布帖子这一类创建资源的操作&＃xff0c;应该只接受 POST 请求&＃xff0c;而 GET 请求应该只浏览而不改变服务器端资源。
• 使用“请求令牌”。首先服务器端要以某种策略生成随机字符串&＃xff0c;作为令牌&＃xff08;token&＃xff09;&＃xff0c;保存在Session里。然后在发出请求的页面&＃xff0c;把该令牌以隐藏域一类的形式&＃xff0c;与其他信息一并发出。在接收请求的页面&＃xff0c;把接收到的信息中的令牌与Session中的令牌比较&＃xff0c;只有一致的时候才处理请求&＃xff0c;否则返回 HTTP 403 拒绝请求或者要求用户重新登陆验证身份。