WebGoat

主要内容：

WebGoat的安装(略)，内部访问方法与后续需要使用的Firebug的一些功能

一．WebGoat安装(略)与访问

二．浏览器推荐使用Firefox

(1)FireBug安装

(2)定位查看页面元素

(3)Js调试

一．WebGoat安装(略)与访问

访问方式：

先配置host: xx.xx.xx.xx https://www.sodocs.net/doc/7214552803.html,

访问URL：https://www.sodocs.net/doc/7214552803.html,:8080/webgoat/attack

用户密码和密码是：guest/guest

二．浏览器推荐使用Firefox

在完成WebGoat的任务时，会有修改页面元素的部分，FireBug是个很不错的工具，可以助你早日通关，下面介绍下FireBug中之后我们会用到的几个功能

(1)FireBug安装

点击工具->附加组件打开组件管理器

获取附加组件中搜索FireBug，点击安装即可

打开FireBug,下面标记的是我们重点将用到的三个按钮

(2)定位查看页面元素

当我们激活”查看页面元素”按钮的时候，鼠标在页面移动时会有一个蓝色的框高亮显示当前鼠标所在元素，相应的下面HTML栏里面会在DOM树里面找到该元素所在位置，如下图所示

找到该元素后，点击左键确认，释放” 查看页面元素”按钮功能，这时我们就可以在HTML栏里面修改该元素的值

比如我要把” How To Work With WebGoat” 修改成“Welcome to Paipai”

点击，输入

查看页面，应该是即时生效了

(3)Js调试

注意上图中，脚本项要设置为”启动”

在这里我们用WebGoat中的一个实例来显示这个功能

实例位置：AJAX Security 下面的Insecure Client Storage

目标：用户输入一个coupon后点击”Purchase”，前台Js会验证code的有效性，我们要通过修改Js运行时的变量值跳过这个检查~

使用”查看页面元素”工具查看coupon code输入框，发现提交时，验证coupon code的js函数是javascript/clientSideValidation.js中的isValidCoupon(field1.value)函数

我们选中脚本栏，选择javascript/clientSideValidation.js文件，就可以找到isValidCoupon函数，或者在右侧的搜索框中直接输入isValidCoupon也可以查找到isValidCoupon函数

查看isValidCoupon函数，可以发现下图红框处就是判断coupon code是否合法的关键代码行了，在行数左侧点左键，设置一个断点

在coupon code的输入框内输入任何一个字母：

这时激活了onkeyup事件，调用isValidCoupon，程序运行到我们设置的断点处

可以看到我们输入的是coupon = 1

把鼠标放到变量decrypted上，显示decrypted = “PLATINUM”

要是函数返回ture，我们需要coupon == decrypted成立，所以我们在右边的监控栏中把coupon 的值改成PLATINUM

鼠标移动到coupon上看看coupon的值已经被修改，点击运行按钮，通过~

主要内容：

Access Control Flaws

访问控制缺陷，这个栏目下的Bug属于将业务的关键逻辑放在了前台，而后台也没有作相应的校验，导致用户可以通过修改前台页面，跳过验证逻辑操作后台数据

Using an Access Control Matrix

Bypass a Path Based Access Control Scheme

LAB: Role Based Access Control 3

Stage 1: Bypass Business Layer Access Control 3

Using an Access Control Matrix

这个Bug属于程序员在作权限控制时的失误，题目提示：

Only the [Admin] group should have access to the 'Account Manager' resource.

分析

这道题的目的是想让我们找出不是Admin但是能访问'Account Manager' resource的人

方法

而我们的攻击方式就是不断的尝试user和resoure的组合

发现Larry用户的身份是[User, Manager]，访问Account Manager权限时竟然被验证通过了Bypass a Path Based Access Control Scheme

在这一题里面我们有一个文件列表，点击“View File”可以访问相应的文件，“Current Directory is:”告诉了我们文件的绝对路径，我们的目的是访问一个不在文件列表中的一个数据，比如

tomcat/conf/tomcat-users.xml

分析

程序访问的文件的方式应该是目录路径：

/usr/local/services/WebGoat/tomcat/webapps/webgoat/lesson_plans/English

接上我们选择的文件名称，而我们要访问的文件是：

/usr/local/services/WebGoat/tomcat/conf/tomcat-users.xml

我们要从English文件夹访问到conf文件夹中的内容，那只有使用相对路径了，所以

/usr/local/services/WebGoat/tomcat/webapps/webgoat/lesson_plans/English/http://w https://www.sodocs.net/doc/7214552803.html,/https://www.sodocs.net/doc/7214552803.html,/conf/tomcat-users.xml

所以我们的目的就是向后台提交文件名

https://www.sodocs.net/doc/7214552803.html,/https://www.sodocs.net/doc/7214552803.html,/conf/tomcat-users.xml

方法

我们用启动FireBug用页面查找找到Select的第一个选项AccessControlMatrix.html，它的值为 AccessControlMatrix.html

当我们点击“View File”按钮的时候，提交的就是选中option的value，所以我们把AccessControlMatrix.html选项的value改成

https://www.sodocs.net/doc/7214552803.html,/https://www.sodocs.net/doc/7214552803.html,/conf/tomcat-users.xml

这样选中AccessControlMatrix.html点“View File”的时候

提交的值就是我们想要的

https://www.sodocs.net/doc/7214552803.html,/https://www.sodocs.net/doc/7214552803.html,/conf/tomcat-users.xml

LAB: Role Based Access Control

这道题有4个步骤，每一步解题方式都类似，下面以第一小题为例

Stage 1: Bypass Business Layer Access Control

这一题需要登陆后操作，根据题目的提示，每一个用户的密码是用户名开头的字母小写，比如用户Larry Stooge (employee)的密码就是larry, Moe Stooge (manager)用户的密码就是moe。我们登陆Tom Cat用户

由于Tom Cat只是普通员工，无法查看，也不能删除其他用户的信息，而我们的目的是要利用Tom 用户突破权限限制，删除某个员工的信息

分析

这个题目应该是把用户权限校验放在了前台，用户提交请求后，后台也没有验证用户的权限，导致用户可以越权操作。要执行删除操作，首先我们得找到删除请求CGI的名称，所以我们得找一个有删除权限的用户，找到删除CGI,然后登陆Tom提交删除请求~

方法

登陆hr Jerry Mouse，发现

Jerry有删除用户信息的权限，我们用元素查找工具把这个Button的代码找到

“DeleteProfile”的内容如下，记录下来

这时，我们重新登陆Tom Cat用户，

把

改成

选择Tom Cat，点击。

完成任务~，利用同样的操作，如果我们想删除其他人信息怎么办呢？

下面同理可得

Stage 2: Add Business Layer Access Control

Stage 3: Bypass Data Layer Access Control

Stage 4: Add Data Layer Access Control

Remote Admin Access

主要内容：

网页Ajax程序与服务器交互返回内容包括无格式文本，Json串，Xml串，回调的Js代码，而这些返回的信息存在有哪些威胁呢?

DOM-Based cross-site scripting

LAB: Client Side Filtering

Same Origin Policy Protection

DOM Injection

XML Injection

JSON Injection

Silent Transactions Attacks

Dangerous Use of Eval

Insecure Client Storage.

DOM-Based cross-site scripting

基于DOM的CSS(即XSS)漏洞

分析

基于DOM的CSS(即XSS)漏洞一般都是由于JS没有对输入的参数作过滤，导致用户可以输入一些XSS载体标签。

在输入框中，我们输入常规的字符发现上面都会出现Hello, XXX的显示

找到输入框的HTML代码，在键盘输入之后会激活displayGreeting事件，并将输入框中的内容作为参数传入

查看displayGreeting函数displayGreeting没有对参数做任何过滤，直接就替换了greeting的内容，这样我们就可以分析页面代码直接输入想要的标签来进行攻击了

greeting标签的内容如下

方法

输入

或者

这样就可以发起CSRF攻击了

但是这种漏洞的攻击模式在哪呢?需要用户打开这样的页面，还要骗取用户向这样的输入框里面输入攻击者发过去的信息，有难度，模式待研究….

LAB: Client Side Filtering

修改larry的id值，Neville的ID为112，选择larry，这样就可以看到CEO Neville的信息了

由此可见，重要逻辑的判断千万不能放在客户端

Same Origin Policy Protection

同源保护

DOM Injection

这个漏洞的意思应该是我在输入框内输入字符的时候会有一个ajax请求到后台验证我输入的key是否合法，然后决定是否激活Activate按钮，理论上应该是要返回我输入的内容，这样我在输入的内容里面插入Js在返回的时候就会被执行，这样就可以修改Activate按钮的属性达到Dom Injection 的目的呀~

但是题目意思好像是要拦截返回包，修改返回包内容达到目的，我们简单点，直接改页面：

修改Activate!按钮的属性，把disabled删去~

XML Injection

查看accountID输入框：

当我们输入完6位accountID后，js会发起一个ajax请求：

https://www.sodocs.net/doc/7214552803.html,:8080/webgoat/attack?Screen=3825&menu=400&from=ajax&ac countID=836239

返回包内容为：

WebGoat Mug 20 Pts

WebGoat t-shirt 50 Pts

WebGoat Secure Kettle 30 Pts

然后回调calback()函数

题目的意思是我们可以修改返回包的内容，但是我修改了n次总是没有成功。。。

所以只能通过修改页面代码来达到目的了，方法如下：

安全中心XML注入漏洞(from jima?s ppt)

JSON Injection

这个和上面的XML Injection一样，不过这次服务器返回的是Json串

{

\"From\": \"Boston\",

\"To\": \"Seattle\",

\"flights\": [

{\"stops\": \"0\", \"transit\" : \"N/A\", \"price\": \"$600\"},

{\"stops\": \"2\", \"transit\" : \"Newark,Chicago\", \"price\": \"$300\"}

]

}

我们把600改成一个较小的值就可以了

同样是修改Callback函数内的返回值，req.responseText的值还是没修改成功，直接修改了card 的值，方法如下

这个XML Injection和JSON Injection漏洞的做的有点牵强，应该要有用户提交数据，然后提交的数据被包装到一个Xml或者Json里面结果，而数据没有过滤就被包装，破坏了预期的Xml或这Json格式，导致页面显示不正常

Silent Transactions Attacks

这个案例里面我们点击”Confirm”之后，JS会校验余额是否足够然后给后台发送转账申请，，如图：我们的余额是11987.09，而我们需要200000，怎么办呢?

我们跟踪Js到判断余额的地方，将我们的balanceValue修改得比我们的amount大一点就可以了~

另外一种方式就直接抓个包：

https://www.sodocs.net/doc/7214552803.html,:8080/webgoat/attack?Screen=4075&menu=400&from=ajax&n ewAccount=1&amount=2000000&confirm=Transferring

修改Amount的值，发送，返回

The Transaction has Completed Successfully.

Dangerous Use of Eval

这个漏洞的威胁在于，回调函数使用了Eval(“返回包内容”)，而返回包的内容用户是可以自定义的

点击” Purchase”我们发现会有弹出框，内容为我们填入的number和code，如果我们在number 和code里面填入Js会怎样呢?

我们跟踪Purchase按钮的提交事件：

在purchase函数中我们没有发现alert(“”)的地方，继续寻找

终于在makeXHR函数中发现了Eval的踪影~

而我们一直寻找的alert就在这里~

http_request.responseText的内容：

"\r\nalert('Purchase completed successfully with credit card \"4128 3214 0002 1999\" and access code \"123\"');\r\n"

了解原理后，我们尝试修改number值，插入js代码运行

如下，返回包中标记红色的就是number的内容

"\r\nalert('Purchase completed successfully with credit card \"4128 3214 0002 1999\" and access code \"123\"');\r\n"

我们尝试闭合语句，');alert('xss');('

这样子就可以插入任意的Js,来执行我们想要的操作了～

Insecure Client Storage

这个漏洞在于把信息（coupon code）存储到了客户端

查看coupon code的事件，找到验证code的js

在isValidCoupon中发现：

搜索coupons发现在coupon code 存储在Js文件顶部：

这样任何访问页面的用户就可以免费获得这些code了

主要内容

保存，反射型Xss，CSRF及HttpOnly的特性

Phishing with XSS

LAB: Cross Site Scripting

Stage 1: Stored XSS.

Stage 2: Block Stored XSS using Input Validation

Stage 3: Stored XSS Revisited

Stage 4: Block Stored XSS using Output Encoding

Stage 5: Reflected XSS.

Stage 6: Block Reflected XSS.

Stored XSS Attacks.

Reflected XSS Attacks.

Cross Site Request Forgery (CSRF)

CSRF Prompt By-Pass.

CSRF Token By-Pass.

HTTPOnly Test

Cross Site Tracing (XST) Attacks.

Phishing with XSS

分析

如图所示，我们输入任何内容，点击“Search”后会显示在左下角，

查看左下角内容的HTML源码，看是否有需要闭合的标签

方法

很完美，无任何限制。。。

输入

或者钓鱼(为了排版我用回车截断了)

结果如下图：

LAB: Cross Site Scripting

Stage 1: Stored XSS

这个案例需要执行一个保存型的XSS

分析

普通职员可以修改查看自己的资料，管理员可以查看普通职员的资料

1.在职员larry的个人资料中插入xss脚本

2.管理员在查看larry的个人资料时运行脚本中招~(这样就可以盗取管理员身份,或者利用管理员身份来干点其他事CSRF)

方法

1.登陆larry用户，修改用户资料，把Street修改为，

点击” UpdateProfile”之后立即弹出窗口，说明这个XSS是可行的~

然后退出Larry用户，登陆Moe查看Larry的信息，验证攻击是否成功~

Stage 2: Block Stored XSS using Input Validation

THIS LESSON ONLY WORKS WITH THE DEVELOPER VERSION OF WEBGOAT

Stage 3: Stored XSS Revisited

THIS LESSON ONLY WORKS WITH THE DEVELOPER VERSION OF WEBGOAT

Stage 4: Block Stored XSS using Output Encoding

THIS LESSON ONLY WORKS WITH THE DEVELOPER VERSION OF WEBGOAT

Stage 5: Reflected XSS

分析

当客户端发送什么，服务器就返回什么的时候，就会出现反射型XSS,比如搜索框

方法

登陆一个manager

在搜索框中输入

Stage 6: Block Reflected XSS

THIS LESSON ONLY WORKS WITH THE DEVELOPER VERSION OF WEBGOAT

Stored XSS Attacks

分析

保存型Xss是攻击者将Xss代码保存在服务器上，任何用户访问都会中招~

方法

输入以下数据:

Reflected XSS Attacks

上一节已经讲过了，这里还可以输入

Cross Site Request Forgery (CSRF)

分析

这个和XSS类似，不过XSS是骗取用户的信息，然后复制用户身份进行攻击

CSRF不用获得用户信息,在消息中插入，如果用户在看这封邮件的时候，正好登陆了paipai,又一不小心点击了下面这个链接，那么被害者就会执行攻击者发送的CGI命令xxcgi(可能是改价，删除商品等敏感操作)

点我你就中招了

或者

前者需要用户点击，而后者用户看到这个帖子的时候就自动发送了请求~

CSRF Prompt By-Pass

分析

这个攻击需要两部，一次输入转账的数目，第二次确认，没有验证码的时代好危险。。。。

方法

CSRF Token By-Pass

。。。我倒，不知道怎么就过了

HTTPOnly Test

关于httponly:

If the HttpOnly flag (optional) is included in the HTTP response header, the cookie cannot be accessed through client side script (again if the browser supports this flag). As a result, even if a cross-site scripting (XSS) flaw exists, and a user accidentally accesses a link that exploits this flaw, the browser (primarily Internet Explorer) will not reveal the cookie to a third party.

大家可以看看httponly设置前后Js读取Cookie的情况

Cross Site Tracing (XST) Attacks

老bug，忽略

主要内容：

SQL注入，Log注入

Command Injection.. 2

Numeric SQL Injection.. 2

Log Spoofing.. 2

XPATH Injection.. 2

LAB: SQL Injection.. 3

Stage 1: String SQL Injection.. 3

Stage 2: Parameterized Query #1(略) 3

Stage 3: Numeric SQL Injection.. 3

Stage 4: Parameterized Query #2(略) 4

String SQL Injection.. 4

Modify Data with SQL Injection.. 5

Add Data with SQL Injection.. 5

Database Backdoors. 5

Blind Numeric SQL Injection(略) 5

Blind String SQL Injection(略) 5

Command Injection

由ExecResults for '/bin/sh'可以得到执行目录，so取passwd的路径如下

修改页面元素的值，让他指向一个系统文件

然后点view~

。。。好像怎么输入都可以pass。。。

Numeric SQL Injection

根据执行SQL

SELECT * FROM weather_data WHERE station = 101

注入SQL

SELECT * FROM weather_data WHERE station = 101 or 1=1

修改属性值

提交查看结果如下：

Log Spoofing