Secure Code Warrior - Fail securely
Download as PPTX, PDF0 likes289 views
The document outlines the concept of 'fail securely' in application security, emphasizing the need for secure handling of exceptions to prevent unauthorized access and security vulnerabilities. It provides examples of proper authentication processes and highlights risks associated with improper error handling, including man-in-the-middle attacks and faulty login mechanisms. Best practices include implementing robust error handling, using generic error messages, and ensuring the application remains in a secure state following a failure.
Secure Code Warrior - Fail securely
- 1. Fail Securely Application Security Fundamentals by Secure Code Warrior Limited is licensed under CC BY-ND 4.0
- 2. What’s the concept about? Fail securely is about how an application should behave in case an unexpected situation occurs. All exceptions should be handled in a secure way. What could happen? Run time errors could interrupt execution thereby causing failures that impact the application’s security. A failure during authentication or authorization could grant a user higher privileges than allowed. How to implement it? Unless a user explicitly received permission to a certain part of the application, he/she should be denied access. All actions should have a determined outcome and exceptions must be handled using generic error messages.
- 3. login(password){ if password correct redirect to token; else redirect to error; } tokenRequest(token){ if token correct user.loggedIn=true; redirect to profile else redirect to error; } Fail Securely Understanding the concept A user wants to log in to his web mail that uses 2 factor authentication. This means the user has to provide his password and a valid one time token to receive access. As a first step, the user successfully enters his password. In case a correct token is provided, the user is redirected to his profile page. In case of a wrong token, the user is presented with an error page and is not logged in. Next, the user is required to enter a valid one time token that is sent to his mobile phone number. Security control failure My Web Mail LOG IN User: H4x0r Pass: *** login failed Log In User: JohnDoe Pass: ******** Log In User: JohnDoe Token: **** Error! Wrong token My profile Welcome, John Doe! Correct token Wrong token
- 4. login(password){ if password correct user.loggedIn=true; redirect to token; else redirect to error; } tokenRequest(token){ if token correct redirect to profile else redirect to error; } Fail Securely What could happen with the concept An attacker was able to determine another user’s password and wants to access that user’s web mail. The attacker successfully enters the password and continues to the next step. The attacker is redirected to an error screen. However, because of a faulty login failure mechanism, the attacker can forcefully browse to the profile page. The attacker is requested to enter a one time token, which he does not possess. The provided token is wrong. Security control failure My Web Mail LOG IN User: H4x0r Pass: *** login failed Log In User: JohnDoe Pass: ******** Log In User: JohnDoe Token: **** Error! Wrong token My Profile Welcome, John Doe! /myprofile
- 5. Fail Securely Understanding the concept A user wants to browse his bank’s mobile application while using free WiFi. An attacker has been able to position himself as a man-in-the-middle and intercepts the user’s communications. The failure is correctly handled and the user is presented with a warning and cannot continue using the app. The application performs SSL pinning and cannot verify the authenticity of the server’s certificate. TLS verification failure Check certificate Application Server HTTPS Warning: Cannot connect
- 6. Fail Securely What could happen with the concept A user wants to browse his bank’s mobile application while using free WiFi. An attacker has been able to position himself as a man-in-the-middle and intercepts the user’s communications. The failure is not correctly handled. The application continues communication using HTTP allowing the attacker full control over the traffic. The application performs SSL pinning and cannot verify the authenticity of the server’s certificate. TLS verification failure Check certificate Application ServerHTTPS HTTP
- 7. Fail Securely Typical controls Identify areas of failure at design time. Every block of code should only have three determined outcomes: • User is authorized Execute actions • User is NOT authorized Don’t execute actions • Exception happens Roll back actions & show error message Implement robust error handling. Use a generic error message in case of an exception. Make sure the system is in a secure state after failure. Also review global exception handling behavior. Secure state Rolled back transactions Released resources Invalidated session