WebGoat第三关：AJAX Security

3-1 DOM-Based cross-site scripting

3-1要求你做的工作是进行跨站脚本攻击，也就是进行javascript注入，如果熟悉前端html代码和javascript可以很容易的做出来，如果不熟悉，额，怎么做也做不出来了吧。

所谓的跨站脚本攻击也就是利用网页的某些漏洞，比如讲用户提交的内容不加任何处理就放在html中作为内容显示出来，据此可以注入javascript来改变网页本身的逻辑以达到我们想要的目的，比如在某一个bbs中注入js窃取所有查看你帖子的用户的cookie等。

在本关中，所用到的技术无非是img标签，js的alert，button的点击事件，以及iframe标签，相应原理也很容易理解，故不再多费口舌。

3-2

3-2-1 本关要求你作为一个CSO Moe Stooge，去查看你没有权限的查看的内容，即CEO的薪水。

所用到的方法无非是通过某些手段直接找到CEO的数据所在，通过关卡名称Client Side Filtering我们大概可以知道，对于权限的判断是在客户端进行的，换句话说，决定你的权限能看到的内容是在客户端通过js来判断执行的，因此我们可以通过绕过JS的手段来达到我们的目的。

解法有很多，第一种解法是当我们首次点击下拉列表时，通过webscareb截取http请求会发现产生一个请求向服务器端请求下拉列表的数据：

然后服务器返回信息：

通过这个返回结果我们直接可以看到CEO的信息，在页面上输入即可通关。

解法二：通过使用FIREFOX的DEBUG来分析页面脚本，可以发现点击下拉列表时会确定一个uid，然后根据这个uid把响应数据显示出来。再往下会找到所有表格的数据，直接提取出来即可。

解法三：下拉列表会确定一个uid，而CEO的uid是112，所以通过webscareb截取http响应包，把其它某人的下拉列表的value改成112，然后选择此人即可看到CEO的信息。

经验与教训：别把任何判断逻辑使用前端javascript实现，想绕过这个逻辑是在太容易了。

 

3-2-2 让你通过修改代码修复这个漏洞，本人不懂JSP，所以放弃。

 

3-3 Same Origin Policy Protection

莫名其妙的关卡，我就尝试性的点了两个连接就通关了，不知道是在考什么知识，查看solution居然说没有找到，真是无语。

 

3-4 DOM Injection

通过分析页面JS可以发现，在TEXT框中输入后会触发 onkeyup事件，在事件处理函数中向服务器发送一个请求，然后回传一段js代码，然后通过eval函数使浏览器执行这段代码。

但是在我尝试的时候无论怎么输入都没有触发onkeyup事件，所以这里采用另外一种解法，反正让那个按钮激活就行了吧。

首先我们来看按钮为啥不能点，查看页面源代码发现是因为有一个disable域，所以通过截取http响应包，把这个域直接去除即可。

通过webscareb截取找到相关代码如下：

去掉后点击激活即可通关。

经验教训：别把验证逻辑放在JS里。

 

3-5 XML Injection

XML注入，先通过一次正确的操作来看看页面本身的逻辑。当你在textbox里输入完你的id的时候，浏览器会使用js向服务器发送一个请求，然后服务器回传一段xml代码，通过这段代码实例化底下的checkbox框，当你选中后点提交时，又会产生一个请求，包含你点击的项的id。

当我们明白了代码逻辑之后，起码能想出两种解决方案，第一是操纵回传的xml代码，第二是操纵提交后产生的请求，标准的solution给的是第一种方法，所以在这里我给出第二种方法。

截取点击了checkbox后的请求，发现是如下格式：

请求本身只有check1001=on check1002=on check1003=on ，所以我们自行加上check1004=on和check1005=on，至于为啥是1004和1005，我按前面的递增顺序猜的，不过从结果来看，猜的还不错。

提交后通关。

经验与教训：别把验证逻辑，哦不，任何重要的逻辑都别放在js中实现了，另外如果使用post传值起码加加密，或者采用些别人不好猜的字段，还有居然连accountid都使用post传值过去，起码也应该在服务器端掉session实现吧魂淡。

 

（未完待续）