OWASP Browser’s “Refresh” Browsers store Headers, ‘POST’ variables sent to web server while fetching a page When a ‘Refresh’ button is clicked, the request to load the current page is re-submitted to server.
OWASP Pre-requisite User leaves the browser window open Adversary gets physical access to the machine.
OWASP Step 1: Bob logged out of the application but did not close the browser. You have been logged You have been successfully logged out.
OWASP Step 2: Alice gains access to his machine. She clicks ‘Back’ button on the browser till she reaches the immediate page after login
OWASP Step 3: Alice clicks ‘Refresh’ button to load this page
OWASP Step4: Alice clicks ‘Retry’ on the pop up by browser and she gets logged in as BOB
OWASP Step 5: Alice intercepts this request with the web proxy, she is able to see Bob’s username & password
OWASP Solutions Introduce an intermediate page Use salted hash technique
OWASP Under the hood POST Login ID+Password POST Login ID+Password BrowserServer Intercept Myhome.asp authenticates the user and is displayed to user Login.asp Myhome.asp
OWASP Intermediate Page Solution Redirect to Myhome.asp POST Login ID+Password Get Myhome.asp Browser Server Intercept Get Myhome.asp Authentication.asp Verify the authentication token and serve the Myhome.asp page Set an authentication token Verifies the authentication token and invalidates the request Login.asp Authenticates the user and assigns session token Myhome.asp
OWASP Browser Memory #2
OWASP Browser Memory Username and password submitted through web page are stored in the browser memory
OWASP Pre-requisite User leaves the browser window open after logging out. Adversary gets physical access to the machine.
OWASP Step 1: Bob logged out of the application but did not close the browser You have been successfully logged out.
OWASP Step 2: Alice views Browser memory and locates the credentials
OWASP Solution The variable containing the clear text password should be reset immediately after logon Use salted hash technique
OWASP Remember feature #3
OWASP Two ways Through the application “Remember my login” option Saves a special cookie Through the built-in feature of the browser Browser stores username-password on hard drive at particular locations
OWASP Pre-requisite User activates features to remember login credentials. Adversary gets physical access to the machine.
OWASP The Attack - App. feature Step 1: Bob logged out of application and closed the browser too. Step 2: Alice gains access to his machine. She - views cookie file in the local machine. - She uses login credentials to log into the application OR - She overwrites her authentication token with Bob’s token in her cookie file at her system.
OWASP The Attack – Browser feature Bob turned IE/firefox browser to save password
OWASP Firefox user - Bob had turned firefox browser to save password through ‘Remember passwords’
OWASP While logging to the application the browser prompted with a dialog to save password and Bob chose “Yes”
OWASP Step1: Alice gains access to his machine. She retrieves the password from the stored location. Alice clicks FireFox- Alice can view Bob’s password in clear text!
OWASP IE stores them encrypted… Location : HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Intelliforms\SPW Alice can still retrieve Bob’s password
OWASP Forget Password Feature #4
OWASP The 3 ways to exploit Using Hidden Fields Using variables in URL Using Improper process
OWASP Hidden Fields #4.1
OWASP Hidden Fields Hidden Form Fields represent a convenient way to store data in the browser and are one of the most common ways of carrying data.
OWASP Pre-requisite Adversary knows a valid username
OWASP Step 1: Alice accesses the Forgot password page Hidden field populated by username paladiontest
OWASP Step 2: Alice sets a new password and changes the username to bob’s and clicks on Login Username in hidden field is changed from paladiontest to paladiontest1
OWASP Alice changed Bob’s password Your password has been changed.
OWASP Solution No critical data should be stored in hidden fields. The application should link the user Id to the session information of the user.
OWASP Variables in URL #4.2
OWASP Variables in URL Applications send parameters through the query string.
OWASP Pre-requisite Adversary knows a valid username
OWASP Step 1: Alice accesses the forget password page using web proxy Username in URL She inputs a new password and clicks ‘submit’
OWASP Step 2: Alice intercepts the request through proxy Username in request
OWASP Step 3: Alice changes the username to Bob Username changed to bob
OWASP Solution No critical data should be sent in query string. The application should link the user Id to the session information of the user.
OWASP Improper Processes #4.3
OWASP Improper Processes Different ways to implement forgot password feature Secret question User details
OWASP Pre-requisite Social Engineering techniques are applied
OWASP Step 1: Alice inputs bob’s name into the username field and clicks on the Forgot password link.
OWASP Step 2: Alice fills Bob’s information
OWASP Step 3: Alice enters the guessed answer
OWASP The new password
OWASP Solution Short lived, one time use, SSL enabled link mailed to user
OWASP SQL Injection #5
OWASP The SQL Injection A well known attack Specially crafted input manipulates SQL Query Attackers can manipulate the database
OWASP Step 1: Alice logs in and accesses the Change password page Enter the string test123‘;-- in the new Password field
OWASP The Attack The password is reset for all users. The query UPDATE SET Password = ‘test123’;--’ WHERE Username = ‘alice’ and old_Password = ‘alice123’
OWASP Solution Strong input validation Maintain a white list Parameterized queries Parameterized stored procedures