The Murky World Of Securing Your Application's Registration Page

Introduction

As cybersecurity leaders, we have to create our message of influence because security is a culture and you need the business to take place and be part of that security culture. Britney Hommertzheim

The purpose of this document is to to provide app devs and programmers of any level a primer for discussing the development of an application's registration page; this was also written with the MERN Stack in mind. The viewpoint is one taken from a grey-hat; As such:

The Material Below Is Safe To Discuss & Develop Responsive Counter-Measures Against,

The Material Below Is NOT Safe To Run On Any Live Applications You Do Not Own Or Have Explicit Written Consent From The Application Owner To Test,

Additionally, I relinquish full responsibility & liability of your own actions onto you,

Ignore My Advice At Your Own Risk And The Result Can Very Well Be:

You Go To Jail.

Kinesthetic Learner? I am too, so I get it.

If you want to try any or all of the techniques listed below, my recommendation is that you build a test platform on your personally owned (company is not okay) device using whatever Technology Stack you desire; then set up a local environment on your device. From there, build a simple registration page that is linked to a locally hosted back-end database using your own written APIs to manage registration; you also need to build your own front-end. Once you have your application running on an arbitrary port such as 3000, explore the simple application in your browser and use your personally created sandbox to do what sandboxes are meant to do: play.

Side note: I will not provide you with a boiler stack; don't ask. If you can't build your own, you have no business attempting to utilize the techniques listed below. You may still discuss it as an educational exercise.

Concepts

1. Duplicate Registration
2. DOSing
3. Failure to Implement Rate Limiting
4. XSS Injections In Registration Fields
5. Insufficient Email Verification
6. Weak Registration Implementation
7. Weak Password Policy

The Material Below Is Purely For Educational Purposes.

Duplicate Registration

What Are The Problems With Duplicate Registrations?

Duplicate registrations of the same username can result in the original account being overwritten; this can result in data loss. Alternatively, if an account is not overwritten, a duplicate account could expose the same information of the initial user, and essentially allow a hacker to hijack the account. Learn More

White Hat - Mitigation Strategies

1. Ensure unique username ids are attached to accounts if you want to allow duplicate usernames
2. If you don't want duplicate usernames, ensure a check of the unique value field is run against the database prior to adding the user account.

Black Hat Education Alert: Initiating A Registration Duplication Attack

1. Register An Account
   • username: test-account-1
   • password: 0123456789
2. Log Out Of The Newly Created Account, and Navigate Back To The Register Page
3. Attempt re-registration
   • username: test-account-1
   • password: 987654321
   • Does It Log You In? => Success || If Not, Try the next step:
4. Attempt re-registration
   • username: test-Account-1
   • password: 0123456789
   • Does It Log You In? => Poke Around
   • Log out of the application, attempt to log back into the same account and look for any changes to the application.

DOS Susceptible Server

What Are The Problems With A DOS (Denial Of Service) Susceptible Server?

A Denial-of-Service (DoS) attack is an attack meant to shut down a machine or network, making it inaccessible to its intended users. DoS attacks accomplish this by flooding the target with traffic, or sending it information that triggers a crash. Learn More

White Hat - Mitigation Strategies

1. Limit the amount of data that can be sent in a request from the front-end to the back-end.
2. Implement rate limiting the application

Black Hat Education Alert: Probing For DOS Susceptible Server

1. Navigate To The Registration Page
* Fill out the form and enter in a long string username || password (50-100 CHAR)
* If the app returns an Internal 500 error, then the server is susceptible to a DoS Attack.

Failure to Implement Rate Limiting

What Is Rate Limiting?

Rate limiting is used to control the amount of incoming and outgoing traffic to or from a network. Learn More

White Hat - Mitigation Strategies

1. Implement Rate Limiter Strategies Based On Need: User/Geographic/Server.

Black Hat Education Alert: Probing For Missing Rate Limiting Implementations

1.  Navigate To The Registration Page
*  Fill out the form and enter in a valid username and password based on requirements
*  Submit the form and redirect the request to BURP Intruder [Learn More](https://portswigger.net/burp/documentation/desktop/tools/intruder).
  *  Once the request has been intercepted
     *  Append two `§§` chars to the username parameter.
     *  Change the payload to contain a different username
  *  Once the payload is ready, send it to the server.  
  *  If the server returns a 200 response then there is there are no rate implementations in place. 

Username Field XSS Injection Attacks

What Is An XSS Injection Attack?

Cross-Site Scripting XSS attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. Learn More

White Hat - Mitigation Strategies

For ReactJS Specifically, you must handle these attack vectors yourself:

1. dangerouslySetInnerHTML Attr
   • JS Can Be Injected Here
2. a.href Attr
   • Two Types:
     • javascript:code
     • base64enc:data
3. Attacker Controlled Props

Black Hat Education Alert: Launching an XSS Attack

1. Use the following payload for a regular text field: `img src=x onerror=alert('e')"`
2. Use the following payload for an email field: `"svg/onload=confirm('c')"@x.com"
  * For an extra challenge, see if it's possible to bypass any filters if any of the previous steps succeed.

Insufficient Email Verification

What Constitutes As Insufficient Email Verification Process?

Applications with insecure email verification processes can lead to hijacked user accounts. To Learn More About Best Practices For Email Verification Processes See Here

White Hat - Mitigation Strategies

1. Regex Email Validation
   • Good But Not Reliable Enough To Use Alone
2. Post Email Validation
   • Known As 'Double Opt-In':
     • The Email address used For registration will receive an email requesting the account owner verify their email by clicking on a link.
     • Con: A mistyped email will result in the account owner never receiving the email and potentially from being denied a second registration chance.
3. Real-time Email Validation
   • A verification that checks in real-time if the provided domain exists and is able to receive inbound messages in real-time.
4. Batch Email Cleanse
   • A method that is used to clean the email addresses you already hold in your database that has never been validated after an extended period of time

Black Hat Education Alert: Probing For Insufficient Email Verification

   1. Log into the application from the front-end.
   2. Change The Email Address And Submit The Request (Build The API If You Don't Already Have It)
   3. The appropriate response that should be received would be something similar to:

Verification email sent
We sent you an email to verify that you own "email@example.com". 
We'll change your email once you verify that you own it.

   * And display a link that can resend the verification email or cancel the change.
   4.  Copy the resend link, it should look something similar to: 

https://<SOMELINK/>.com/email-change/<CTOKEN/>/resend

   5.  Copy the resend link and navigate to:

https://<SOMELINK/>.com/email-change/<CTOKEN/>/

   6. The email should now be verified even though the account user is not the true owner of the email address.

• Here are some other things to try:
  • Response Manipulation - Change a bad response with a good one like 'false' to 'true'
  • Status Code Manipulation - Change the '403' response code to '200'
  • Forced Browsing - Directly navigate to any malicious files once the post-email verification process is complete.

Weak Registration Implementation

What Are Some Examples Of Weak Registration Implementations?

Weak registration implementations can result in pollution of resources, hijacking of email services, or man-in-the-middle attacks. There are two examples provided in this document:

1. Allowing Registration On A Non-HTTPS Page Learn More
2. Disposable Email Addresses Learn More

White Hat - Mitigation Strategies

1. Secure a server with an SSL certificate and ensure that the application's communicates over an encrypted connection via HTTPS.
2. Implement email verification processes as needed.

Black Hat Education Alert: Probing For Weak Email Verification

    1. Attempt to Navigate to the application using http:// as the protocol.
        * If the above step proceeds, attempt to register an account.
        * If registration is successful, the application is susceptible to traffic sniffing and man-in-the-middle attacks.
    2. Attempt registration with a disposable email address.
        * If the above step is successful, then the application is susceptible to attack.

Weak Password Policy

What Are Some Examples Of Weak Password Policies?

Weak password policies can result in data breaches, loss of data, hijacking of accounts, or worse.

White Hat - Mitigation Strategies

1. Setup basic password
2. Implement deny and allow lists for the most basic processes of the application such as "admin", "companyName", "deptName", the top-ten-worst passwords per year, etc.

Black Hat Education Alert: Probing For Weak Password Policies

1. Attempt to Register with an easily guessable password like 123456/abcdefg 
2. Check if you can use the username as the password.
3. Check if you can use the email address as the password.
* Want an extra challenge? Probe the password-recovery functionality for weaknesses.

Contact me

1. Author: Dustin K Greco
2. Email: dkgreco@thegemtrove.tech
3. Phone: 1-928-457-0764