Web Application Security Testing

WEB APPLICATION SECURITY TESTING – 6. ATTACKING AUTHENTICATION

 

This notes is for learning/educational purpose only. Use it at your own risks. 

 AUTHENTICATION TECHNOLOGIES

Wide range of technologies are available for authentication mechanism :

  • HTML form-based authentication
  • Multifactor mechanism like combining password and physical tokens
  • Client SSL certificates and/or smartcards
  • HTTP authentication
  • Windows-integrated authentication using NTLM or Kerberos

90% of web apps use form based authentication.

  • More secure methods would be two-factor authentication i.e. PIN from token, SMS message or mobile app, in addition to password.
  • Cryptographic methods are client side SSL certificate, smartcards etc, but expensive.
  • HTTP authentication including windows integrated are often found on intranets, not on internet.
  • Third party authentication services i.e. using OAuth etc.

DESIGN FLAWS IN AUTHENTICATION MECHANISMS

Bad Passwords

  • Short or blank, dictionary based, same as username or set to default value.

Brute-forcible Login

  • Attackers use list of common passwords. Account lockout is the defense.

Verbose Failure Messages

  • Friendly for legitimate users but helpful for attackers i.e. harvesting valid username

Vulnerable Transmission of Credentials

  • Unencrypted credentials should never be sent even over HTTPS

Password Change Functionality

  • Periodic password change mitigates password compromise is dubious claim. Change password if its compromised.
  • Password change system is vulnerable if:
    • It reveals a username is valid
    • Allows unrestricted guesses of existing password field
    • Checks if new password and confirm new password have same value after validating existing password.

Forgotten Password Functionality

  • Often the weakest link, uses secondary challenge.
  • Small set of possible answers, can be brute-forced or found from public information.
  • Some apps let user in after challenge without login.
  • Some apps disclose password to user.
  • Some apps ask user email id for sending password reset link.

“Remember Me” Functionality

  • Sometimes a simple persistent cookie.
  • No need to login if username or session id can be guessed or found
  • If encrypted, it can be stolen via XSS or by getting acces to user device.

User Impersonation Functionality

  • Company personnel may have access to impersonate users, implemented either as hidden function, guessable session number or fixed backdoor password.

Incomplete validation of credentials

  • Some apps truncate passwords without telling users and also strip unusual characters.

Non-unique usernames

  • Rare, but it might be possible to create new account with same username.

Predictable usernames

  • Automatically generated usernames.

Predictable Initial passwords

  • Usually for user accounts created in large batches. All having same initial password.

Insecure distribution of credentials

  • Passwords sent by email, sms etc.
  • Activation URLs may be predictable.
  • Some apps email new password after each password change.

IMPLEMENTATION FLAWS IN AUTHENTICATION

Fail-Open Login Mechanisms

Blank, invalid username may cause exception in login routine, very long or short values or different character sets and allows the user in.

Defects in Multistage Login Mechanisms

  • May allow user to skip steps.
  • May trust data that passes step one, but let user change it, so invalid or locked out accounts remain available.
  • May assume that same username applied to all three stages but not verify this.
  • May use randomly chosen question to verify user, but let the attacker alter question in hidden HTML or cookie.

Insecure Storage of Credentials

  • Plain text passwords in database.
  • Hashes with MD5 or SHA1, easily cracked.

SECURING AUTHENTICATION

Use Strong Credentials

  • Minimum password length, use of alphanumeric and typographic characters.
    Avoid dictionary words, similar to username or old passwords

Unique usernames

  • Auto generated usernames or passwords should be long and random, so they cant be predicted.
  • Allow users to set strong password.

Handle Credentials Secretively

  • Protect them when created, stored and transmitted.
  • Whole login page should be HTTPS, not just login button.
  • Use POST and don’t put credentials in URL or cookies
  • Don’t transmit credentials back to client
  • Securely hash credentials on server
  • Hashing- Password hashes must be salted (adding random bytes to password before hash) and stretched (many rounds of hashing i.e. 5000 rounds for SHA512)
  • “Remember Me” functionality should remember only non-secret items i.e. usernames
  • If password is stored locally, it should be reversibly encrypted with key known to server only
  • Capture some login info with drop down list instead of text fields to defeat key-loggers

Validate Credentials Properly

  • Validate entire credentials with case-sensitivity
  • Terminate session on any exception
  • Review auththentication logic and code
  • Strictly control user impersonation
  • Multistage login-
    • All data and results of progress must be held in server-side session object not on client
    • No item of information should be submitted more than once by user
    • No means to modify data after submission
    • First task of every stage should be to verify that all prior stages have been correctly completed
    • Always proceed through all stages, don’t give attacker any info about which stage failed

Prevent Information Leakage

  • All authentication failures should use same code to produce same error message.
  • Account lockout can be used for username enumeration

Prevent Brute-Force Attacks

  • Using unpredictable usernames makes brute force attacks more difficult
  • Using different usernames with same password for an attack, can be mitigated with strong password rules i.e. CAPTCHA

Prevent Misuse of Password Change Function

  • Prevent changing username.
  • Require user to enter old password
  • Require new password twice
  • Show same error message for all failures
  • Out-of-band password change notification

Prevent Misuse of Account Recovery Function

  • For security critical apps, require out-of-band account recovery
  • Don’t use password hints
  • Email unique, time-limited, unguessable, single-use recovery URL
  • Don’t let users write their own challenge questions and don’t use questions with low-entropy answers

Log, Monitor and Notify

  • Log all authentication related events and protect logs from unauthorized access
  • Anomalies like brute force should trigger IDS alerts
    Notify users of any critical security events
    Notify users in-band of frequent security events i.e. time and source of last login
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s