Application Security Testing of the Login form guidelines.

INTRODUCTION

This is the second article in the AppSec series, which describes how to test Login 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. IMPROPER AUTHENTICATION — BRUTE FORCE

Send multiple values using parameter pollution or an array variable.

• An attacker can guess a user password using a few requests.

API should not accept multiple values for the parameters during authentication.

II. IMPROPER AUTHENTICATION — ACCOUNT HIJACKING

Use victim email without a password as an additional parameter.

• An attacker could hijack a victim’s account without a password.

API should not allow multiple accounts to be logged in with a single request.

III. “ANONYMOUS” LOGIN

Do not use any data to authenticate or use the only name.

• An attacker could access the application unauthenticated.

API should not allow signing in without credentials.

IV. CLIENT-SIDE VERIFICATION

Manipulate server response after an unsuccessful login attempt.

• An attacker could access the victim’s account with only a valid username.
• The technique can find new endpoints and trigger some new requests without looking into a JS code. It is convenient when the JS code is enormous, and you have little time.

Ensure that client-side security checks are duplicated on the server-side.

V. PUBLICLY ACCESSIBLE ADMIN LOGIN PAGE

Check if any admin login panel is available to the public.

• An attacker could perform a brute-force attack to compromise administrator account credentials or access by exploiting vulnerabilities in the case of unpatched systems.

Restrict admin panel access to only whitelisted IP addresses.

VI. WEAK ADMIN PASSWORD

Check default & common passwords on the admin login page.

Default credentials should be disabled and changed to non-guessable.
The password in use should not be easy to guess.

VII. INFORMATION DISCLOSURE

Check login page source & JS code before and after failed login attempt.

The application should not cache or store sensitive information in an insecure place, such as server response or javascript files.

VIII. 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 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.

IX. ENUMERATION

Check user enumeration via status code|error message|time differences.

• May allow the attacker to guess valid users and use them to perform brute-force and social engineering attacks.

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

X. FAKE LOCKING MECHANISM

Check if you can log in after 100 failed attempts.

• The attacker may perform brute-force attacks.

Implement Time-based lockout or self-service unlock (sends unlock email to registered email address) and as an additional layer rate-limiting and CAPTCHA.

XI. LOCKING MECHANISM RESET

Try to reset the lock by issuing the correct credentials for each “n” time.

• The attacker may bypass the rate-limiting.

import sysif len(sys.argv) !=3:
    print("python brute_ip_ban.py [wordlist.txt] [word_to_add]")
i = 0
new_wordlist = ""with open(sys.argv[1]) as wordlist:
    for word in wordlist:
        i+=1
        if i % 3 == 0: # CHANGE - (default 3rd is valid).
            new_wordlist+= sys.argv[2] + '\n'
        else:
            new_wordlist+=wordf = open('new_' + sys.argv[1], 'w')
f.write(new_wordlist)
f.close

The locking mechanism should be implemented per account.

XII. DE-AUTHENTICATION

Check if the locking mechanism also destroys an active user session.

• An attacker could block the victim's account.

The locking mechanism should not invalidate active user sessions.
Apply Self-service unlock (sends unlock email to registered email address).
Implement rate-limiting and CAPTCHA.

XIII. LOCKING MECHANISM —HEADER BYPASS

Use additional headers after triggering the lock.

• An attacker could bypass the locking mechanism on the login page.

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

The locking mechanism should not be based on other request elements than the user account variable. Additionally, avoid using unnecessary headers.

XIV. LOCKING MECHANISM — PATH & METHODS BYPASS

Use similar paths, random parameters, and methods after the lock.

• The attacker may bypass the locking mechanism.

The locking mechanism should not be based on other variables than the user account.

XV. LOCKING MECHANISM BYPASS — SOURCE IP ROTATION

Use a different IP address to bypass the lock.

The locking mechanism should not be based only on the IP address.

XVI. SESSIONS MANAGEMENT

Use Burp Sequencer to sign-in multiple times without logging out.

All successful authentications should generate a new session ID.
The application should allow a user to see all active sessions and the termination of any one of them. Moreover, the application should invalidate the session on the server-side after the user’s logout.

XVII. SESSION COOKIES SECURITY

Ensure that the proper security configuration is set for cookies.

Set HttpOnly and Secure flags for cookies used for sensitive data storage.
The SameSite parameter should be set to “Lax” or “Strict”.
The session should not be valid after the expiration date-time.

XVIII. SESSION FIXATION — REACTIVATION

Try to activate the expired session cookie.

• An attacker could reactivate the old stolen session cookie of the victim and then hijack his account.

Invalidate the existing session ID before authenticating a user, and if the authentication is successful, provide another session ID.

XIX. SESSION FIXATION — IMPERSONATION

Try to set the session cookie with an arbitrary value.

• An attacker could impersonate the victim session using his cookie if it is not changed when a user logs in.
• Another attack scenario would be setting up cookies, whereby the victim would unknowingly use the attacker’s account.

Implement a session token renewal after a user successfully authenticates.

XX. INFORMATION DISCLOSURE — SIGN-OUT

Check logout page response during the sign-out process.

• There could be some sensitive information leakage or other possibilities of exploitation, such as Snapchat's Improper Authentication.

The application should not cache or store sensitive information in an insecure place, such as server response or javascript files.

XXI. INPUT VALIDATION

Check the INPUT VALIDATION TIPS from the previous blog post.

• Manually check the NoSQL authentication bypass.

• Give a try “unseen SQL Injection”:

Check the Input Validation Cheat Sheet from OWASP.

XXII. DESCRIPTIVE SID NAME

Check if you can fingerprint the server info via SID name.

• The attacker could use information disclosure about the underlying technological stack via session ID name for tailoring attacks.

Change the default session ID name of the web development framework to a generic term, such as “id”.

XXIII. BRUTEFORCIBLE SID

Test session ID entropy level using Burp Sequencer.

• An attacker could guess or predict the ID of a valid session through statistical analysis techniques, thus hijacking the victim session.

The session ID value must provide at least 64 bits of entropy.
Its length must be at least 128 bits (16 bytes).
It must also be unique to avoid duplicated IDs.

XXIV. INFORMATION DISCLOSURE IN THE SID VALUE

Search for any sensitive information in the SID value.

• An attacker can decode the contents of the ID and extract details of the user, the session, or the inner workings of the web application.

The session ID must be an identifier on the client-side, and its value must never include sensitive information.

XXV. INPUT LENGTH LIMITATIONS

Check all parameters value length limits.

• The most common issue is that the hashing mechanism on the password parameter value causes DoS.

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

XXVI. SESSION PUZZLING — REDIRECTION

Abuse redirection prevention to access the account.

• An attacker could hijack any user account by knowing his name.

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

XXVII. MISSING PASSWORD FIELD MASKING

Check if the software does mask passwords during entry.

• Increase the potential for attackers to observe and capture passwords.

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

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

---

Originally posted at: https://systemweakness.com/appsec-tales-ii-sign-in-3e880f16c588