Application Security Testing of the Register form guidelines.

INTRODUCTION

This is the first article in the AppSec series which describes how to test Registration 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. IMPERSONATION

Register twice using the same data but changing the sign-up component.

• The victim’s account could be hijacked if the application allows resetting the password based on one of the sign-up components.
  (Example of hijacking based on the username)
• The attacker may impersonate the victim by using his data from another account.
• The victim’s data can be removed entirely from the database or replaced with new ones entered by the attacker.

Username and other sensitive data such as document number, phone number, personal identification number, International Bank Account Number, etc., must be linked to the existing account and blocked from being used again.

II. SPOOFING

Register twice using: the same email | + |. |uppercase|unicode.

• The attacker could smuggle messages to the victim based on the registration form, which could help in a phishing campaign.
• A victim’s mailbox can be flooded with vast amounts of email messages. Asa result, the mail server can place messages from the target domain in the spam or block them entirely from delivery.
• An attacker could get registration bonuses multiple times.

Sub-addressing generally should not be blocked, but the possibility of creating multiple accounts from the same email address does.

III. UNICODE NORMALIZATION ACCOUNT TAKEOVER

Register account with Unicode letter.

U+0212A normalizes to K and can be sent URL encoded as %e2%84%aa.

• An attacker could use this to hijack an existing account by creating the same one with Unicode characters and assigning different sign-in components (email/username/phone number etc.)
• Records in the database of the old account could be overwritten, which could allow logging in using the new password.

Ensure canonical encoding is used across all the text and that no invalid characters are present. The validator should not accept double registration with Unicode signs.

IV. CREDENTIALS OVER 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 also be 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.

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

V. ACCOUNT VERIFICATION

Check if email verification is implemented correctly.

• If registration is paid by subscription, the attacker could register for free by reusing the token.
• If there is no email validation, it is likely that the database stores all emails once provided in the registration form, which could overload the database with trash data leading to Denial of a Service.
• Suppose the victim has changed the email address linked to the application account and the attacker has compromised their old email account. In that case, he may lose access to the application account due to the unexpired token reuse attack.

Email addresses should be verified before making the website functionalities available. Moreover, the token itself should be at least 32 characters long, generated using a secure source of randomness, single-use, and time-limited.

VI. ENUMERATION

Check if it is possible to enumerate any sensitive information.

• An attacker could brute-force sensitive data depending on the form.

The generic message should be implemented — for example:
“Verification email has been sent”.

VII. PASSWORD POLICY

Check if the password policy complies with current standards.

• The password could be brute-forced easier.
• If the database was leaked, the attacker could easily crack the passwords.

Password policy is volatile. Always refer to the latest Application Security Verification Standard recommendations.

VIII. INPUT LENGTH LIMITATIONS

Check parameter values length limits.

• The most common issue is that the hashing mechanism causes DoS.

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

IX. SSRF

Analyze the callback using Burp Collaborator “[email protected]_collab.net “.

I honestly never found a security bug like this, but analyzing DNS/SMTP interactions with the use of a collaborator may extend the attack surface.

X. RATE-LIMITING

Try to register 1000 accounts in seconds.

• Facilitates the attacker in the enumeration of sensitive data.
• It could lead toe-mail blocking of legitimate people and induce potential Denial of a Service.

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

XI. TRUNCATION

Check if data is truncated after a certain length.

• An attacker could use it to bypass domain whitelisting.
• Like in registering non-existing mail, an attacker could overload the database with only the username part leading to Denial of a Service.

If data limits are set, invalid requests should be rejected rather than truncated to appropriate values.

XII. MASS ASSIGNMENT

Try to register as a privileged user — use the Param Miner extension.

• If implemented, an attacker could get an administration privileged or bypass paying a subscription fee.

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

XIII. IP ADDRESS SPOOFING

Try to spoof registration IP origin using headers.

• If the website uses the value of the below headers as the client IP address, an attacker could change the IP value to bypass the IP source identification.
• Burp Suite Collaborator Everywhere could help with finding this issue.

X-Originating-IP: 127.0.0.1
X-Forwarded-For: 127.0.0.1
X-Remote-IP: 127.0.0.1
X-Remote-Addr: 127.0.0.1
X-Client-IP: 127.0.0.1
X-Host: 127.0.0.1
X-Forwarded-Host: 127.0.0.1

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

XIV. SESSION PUZZLING — USER IMPERSONATION

Check if the registration feature does not override session variables.

• An attacker could impersonate any user account.

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

XV. PRE-ACCOUNT TAKEOVER

Register using no password&password method.

• The attacker could hijack an account that the user created with SSO.
• The attacker could set a trap by registering an account using the victim’s email and waiting for the victim to log in using the no password method.

Email validation should be implemented.

XVI. MISSING PASSWORD FIELD MASKING

Check if the software does mask passwords during entry.

• It is increasing the potential for attackers to observe and capture passwords.

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

XVII. INPUT VALIDATION

Test input validation XSS, SQLi, RCE, SSRF, LFI, RFI…

It is impossible to describe each point of input validation in a single article, and it misses the point of this blog post, but I will give you some tips and links to other sources.

• Check the latest WSTG guidelines.
• If you need more payloads, check PayloadAllTheThings.
• Burp Bounty extension should help a lot too.
• For Out-of-Band testing, I recommend my OOB wordlist.
• If you are looking for some more tools and extensions, check Crimson.
• Especially check how you can inject payloads into an email address (@securinti — You’ve got pwned: exploiting email systems).

Check the Input Validation Cheat Sheet from OWASP.

XVIII. EMAIL ADDRESS VALIDATION

A few of my payloads to test the email address parameter value:

### HTML INJECTION
kmazurek+(<h1>aaa)@example.com
kmazurek(<h1>aaa)@example.com
"kmazurek+<h1>aaa"@example.com
### XSS
kmazurek+(<script>prompt(1)</script>)@example.com
[email protected](<script>prompt(1)</script>).com
"kmazurek+<script>prompt(1)</script>"@example.com
### SSTI
@example.com">kmazurek+${5*5}${{6*6}}@example.com
kmazurek(${5*5}${{6*6}})@example.com
"<%= 7 * 7 %>"@example.com
### SQLi
"' AND sleep(100);-- - "@example.com
"';WAITFOR DELAY '0:0:30';-- - "@example.com
kmazurek+(select * from (select(sleep(10)))a)@example.com
### SSRF
";burp_collab"@example.com
[email protected][127.0.0.1]
### PARAMETER POLLUTION
[email protected]&[email protected]
"email":["[email protected]","[email protected]"]
### CLRF
"[email protected]>\r\nRCPT TO:<kmazurek+"@example.com
### WILDCARD ABUSE
*@example.com
%@example.com
### FUZZ
"FUZZ"@example.com

Check the latest OWASP Email Address Validation.

DIFFICULTIES

TEST SAMPLES

Often, to check the registration form, test data will be needed, especially if we want to test rate-limit or other brute-force attacks. Sometimes, you could use random strings of characters generated in the Burp Intruder, but most of the time, it will have to be specially generated data, e.g.:

• IBAN
• phone number
• National identification number

Sometimes National identification number must also match the date of birth, which even more complicate the case.

However, there is an easy solution: the Faker library made for Python3, which helps generate such data. Below are some commands that generate data based on the pl_PL provider. You can find many other countries to choose from in the documentation.

# python3 -m pip install Faker
from faker import Faker
fake = Faker("pl_PL")
first_name = fake.first_name()
last_name = fake.last_name()
identity_card_number = fake.identity_card_number()
nip = fake.nip()date_of_birth=fake.date_of_birth(minimum_age=18, maximum_age=90)
pesel=fake.pesel(date_of_birth)phone_number=fake.phone_number()
    if phone_number[0:3] == "+48":
    phone_number=phone_number[4:]
phone_number=phone_number.replace(" ","")

The simple solution would be to generate a wordlist all.csv separated by commas and split into wordlists like IBANs.txt,usernames.txt, phone.txt (You can download and modify the template here to create such lists).
Then use the intruder attack type called Pitchfork.

CAPTCHA

You may need to remove the captcha implementation to automate the testing of the registration form. It is good for you if the captcha is turned off during testing; otherwise, try the points below to bypass it:

• Do not send the parameter related to the CAPTCHA.
• Send the CAPTCHA parameter empty.
• Search for the CAPTCHA value in available resources
  (page source code, JavaScripts files, cookie, headers).
• Try reusing old CAPTCHA.
• Try to reverse the CAPTCHA. Maybe it is easily calculated or easy to guess.
• Bypass captcha using OCR — article.

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 find 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 returning 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 ;]

---