1 / 21

Broken authentication and session management

Broken authentication and session management. Daneliuc Ana-Maria, MISS2. 2nd Place in OWASP Top 10 2013 Application Vulnerabilities. vast threat, strongly related to other top 10 vulnerabilities (XSS, Sensitive Data Exposure, CSRF etc.)

aric
Download Presentation

Broken authentication and session management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Broken authentication and session management Daneliuc Ana-Maria, MISS2

  2. 2nd Place in OWASP Top 10 2013 Application Vulnerabilities • vast threat, strongly related to other top 10 vulnerabilities (XSS, Sensitive Data Exposure, CSRF etc.) • includes all aspects of handling user authentication and managing active sessions • unfortunately, not all of these aspects have a standard implementation

  3. Authentication • the process of verifying a user’s identity • commonly performed by submitting a username/user id and more private items that only a given user should know • data is usually persisted in a database

  4. Password guessing attacks • brute force • dictionary attacks

  5. Password guessing attacks • lookup tables (precomputed) – see the CrackStation database • rainbow tables (precomputed) • reverse lookup tables (computed during the attack)

  6. Authentication - Common use cases, attacks and guidelines • Brute force or dictionary attacks • Enforce proper password strength: • Password must meet at least 3 out of the following 4 complexity rules • at least 1 uppercase character (A-Z) • at least 1 lowercase character (a-z) • at least 1 digit (0-9) • at least 1 special character(punctuation) • at least 10 characters • at most 128 characters • not more than 2 identical characters in a row (e.g., 111 not allowed) • the password should not contain parts of the username or targeted application

  7. Authentication - Common use cases, attacks and guidelines • Brute force or dictionary attacks • Lock account after repeated authentication failures and implement a reset password mechanism • Show generic error messages: Incorrect Response Examples • "Login for User foo: invalid password" • "Login failed, invalid user ID" • "Login failed; account disabled" • "Login failed; this user is not active" Correct Response Example • "Login failed; Invalid userID or password”

  8. Authentication - Common use cases, attacks and guidelines • Brute force or dictionary attacks • Use Multi-Factor Authentication • besides the password, another information is needed, sent via an “out-of-band” channel: • email token • hardware tokens • SMS token • Facebook and Yahoo request this when there is a login attempt from an unknown location

  9. Authentication - Common use cases, attacks and guidelines • Passwords database gets compromised => lookup tables & co. • Developers - NEVER store the passwords in clear • use a strong cryptographic hash function (SHA512, SHA-3, WHIRLPOOL etc) to hash them • add salt: hash(password + “cxafZoufdsX”); makes precomputed hash tables useless • do not reuse the salt • always hash on the server side; do not rely only on client side hashing • Users – do not use the same password on multiple websites

  10. Authentication - Common use cases, attacks and guidelines • Man-in-the-middle attacks on the network • Sniffing – intercepting packets over the network • Spoofing – a malicious entity pretending to be an innocent one, by falsifying data

  11. Authentication - Common use cases, attacks and guidelines • Man-in-the-middle attacks on the network (sniffing & spoofing) • All sensitive operations should be enforced under HTTPS • encryption to prevent sniffing – SSL/TLS • authenticationto prevent spoofing – use of Public Key Encryption with certificates issued by a Trusted Authority (e.g. VeriSign, Thwate, etc)

  12. Authentication - Common use cases, attacks and guidelines • Man-in-the-middle attacks on the network (sniffing & spoofing) • Do Not Provide Non-HTTPS Pages for Secure Content • The <form> html action can easily be spoofed to another URL by an attacker who sniffs the html code as it is downloaded from the server • Even worse, the attacker can insert javascript code that steals credentials as you type them

  13. Authentication - Common use cases, attacks and guidelines • Man-in-the-middle attacks on the network (sniffing & spoofing) • Do not mix encrypted and unencrypted contents (HTML pages, images, CSS, Javascript files, etc) on the same host • the request of any web object over an unencrypted channel might disclose the session ID • Use HTTPS for all authenticated pages • failure to utilize TLS for authenticated pages after the login enables an attacker to view the unencrypted session ID (“Set-Cookie: sid=af45e543” header)

  14. Authentication - Common use cases, attacks and guidelines • URL attacks • Do not include sensitive data in the URL, even when using HTTPS • the URL may leak in the referrer header at the destination server • the entire URL is cached in the browser history. This may expose sensitive data to any other user of the workstation. • CSRF (Cross-Site Request Forgery) attacks • Require Re-authentication for Sensitive Features (e.g. buying, updating the credit card number) • in case the attacker is aware of the user being authenticated, it can send or inject a link to perform actions on behalf of the user

  15. Authentication – Use of authentication protocols that require no password • OAuth & OpenID– Facebook, Google, Twitter APIs • Suitable in cases of mobile clients, that can store credentials in a way that the server cannot control

  16. Session Management • A web session is a sequence of network HTTP request and response transactions associated to the same user and managed by the server • The session ID or token binds the user authentication credentials (in the form of a user session) to the user HTTP traffic and the appropriate access controls enforced by the web application

  17. Rules for a good session id Do not use session id name fingerprinting : PHPSESSID , JSESSIONID Use a long enough session id to prevent brute force attacks (at least 16 bytes) Have session id entropy – make the session id unpredictable (E.g. not related to the username in any way)

  18. Session Management – ways to store the session id • Not recommended: • in the URL: https://example.com?SID=dsadas4738 • hidden form fields: <form><input type=“hidden” name=“sid” value=“s8s1sag”/></form> • Recommended: • in cookies having: • “Secure” Attribute, that instructs web browsers to only send the cookie through an encrypted HTTPS (SSL/TLS) connection • “HttpOnly” Attribute, that instructs web browsers not to allow scripts (e.g. JavaScript) the ability to access the cookies via the DOM document.cookie object. • Expire or Max-Age Attributes – prevents long time caching

  19. Session Management – common use cases, attacks and guidelines • Session fixation •  the attacker sets a user's session id to one known to him; it only has to wait for the user to log in • sending a malicious link with the session injected in the URL • XSS by setting the cookie session id: document.cookie=”sessionid=1234”; • Solutions: • Do not accept session identifiers from GET / POST variables: <a href=http://vulnerable.com?SID=MY_KNOWN_SID>Check this out</a> • After successful login, change the session id • Properly invalidate the session id after logout • Use HttpOnly on session cookies

  20. Session Management – common use cases, attacks and guidelines • Session sidejacking • the attacker uses packet sniffing to read network traffic between two parties to steal the session cookie or to read the “Set-Cookie” header after login, proceeding with session fixation afterwards • the cookie session id has a predictable generation algorithm and we can guess a session id and bypass authentication • Solutions: • Only use HTTPS for authentication and session cookies with “Secure” attribute • Use a strong random generator for the session id • Do not accept the header “Cookie: sid=adf45632” from any other user agent other than a browser

  21. Resources Most OWASP resources: https://www.owasp.org/index.php/Authentication_Cheat_Sheet https://www.owasp.org/index.php/Session_Management_Cheat_Sheet https://www.owasp.org/index.php/Session_fixation https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management - lists other important tools also https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project – WebGoat Project, available in most programming languages https://crackstation.net/hashing-security.htm - About correct password hashing ESAPI Authenticator and User APIs – An Authentication API made by the OWASP community

More Related