AppSec Tales II | Sign-in - Pentestmag

AppSec Tales II | Sign-in

AppSec Tales II | Sign-in

by Karol Mazurek


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.
Source: Own study — Examples of password guessing and spraying attack.

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.
Source: Own study — Example of account hijacking attack.

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.
Source: Own study — Accessing the application without valid credentials.

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.
Source: Own study — Intercepting response to the login request.
Source: Own study — Changing response from “403 Forbidden” to “200 OK” and forwarding it.

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.
Source: Own study —  -kre -w wordlist.txt -o out.txt -u  -H “$cookie”

Restrict admin panel access to only whitelisted IP addresses.

VI. WEAK ADMIN PASSWORD

Check default & common passwords on the admin login page.

Source: Own study — Testing weak passwords using  & .

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.

Source: Own study — Using Burp Comparer to check differences in both responses.

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.
Source: Own study — Example of sensitive data transmitted in the path using HTTP.

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.
Source: Own study — Enumerating usernames on the login page.
Source: Own study — Testing enumeration using time differences.

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.
Source: Own study — Example of a fake locking mechanism response (status code).

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.
Source: Own study — Testing Denial of a Session locking mechanism.
Source: 

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.
Source: Own study — Using headers to bypass the locking mechanism.
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.
Source: Own study — Testing locking mechanism parameter bypass.

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.

Source: Own study — Testing locking mechanism source IP bypass ().

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

XVI. SESSIONS MANAGEMENT

Use  to sign-in multiple times without logging out.

Source: Own study — Session management testing flow.

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.

Source: Own study — Cookies security checks.

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.
Source: Own study — Reactivating & reusing the expired session cookie.

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.
Source: Own study — Impersonating another user account with session fixation.

Implement a session token renewal after a user successfully authenticates.

XX. INFORMATION DISCLOSURE — SIGN-OUT

Check logout page response during the  process.

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 .

Source: Own study — XPath & Ldap & SQLi testing ().
  • Manually check the  authentication bypass.
Source: 
Source: 
Source: Own study — Using Burp build-in wordlists for authentication bypass.
Source: Own study — Using  extension for sending 10 000 000 “A” chars in the password field value.

Check the  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.
Source: Own study — Examples of descriptive SID names ().

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.
Source: Own study — Testing the SID entropy level using Burp Sequencer.

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.
Source: Own study — Information not considered sensitive in session token space.

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.
Source: Own study — Proper length limitations.

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.
Source: Own study — Session puzzling testing flow.

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.
Source: Own study — Example of missing password field masking.

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

August 9, 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