Broken Authentication & authorization
Download as PPSX, PDF1 like843 views
- The document discusses common issues with broken authentication and authorization in web applications, providing several case studies as examples. It covers topics like authentication bypass through misuse of auth tokens, cookie manipulation, and session invalidation. It also discusses authorization bypass through privilege escalation via role changes and direct access to privileged pages. The document concludes with recommendations on how to properly implement authentication, authorization, and access controls to prevent such issues.
![Case 5 – Authentication bypass in
Mobile App
Login Scenario:
• On successful login, user session was stored in local
/AppData/ folder (sqlite db).
Attack Scenario:
• After analyzing the sqlite db, it was observed that the stored
session is nothing but triple encoding of the username in the
format [{username}]
• Attacker encodes the victim’s username thrice and pushes in
the device’s AppData folder.
• Opens the App in device.
RESULT: Attacker gets logged in to victim’s account](https://image.slidesharecdn.com/brokenauthnauthz-180216051724/85/Broken-Authentication-authorization-13-320.jpg)
![Case 1 - Boolean based privileges
Application Design:
• Application has only two privileges – Admin & normal user.
• Keeps track of privilege by Boolean parameter
[isAdmin/Admin/SuperManager]=[true/false].
• Admins have additional content which are unavailable for normal
user.
Attack Scenario:
• Attacker who is a Normal low privilege user logs in with valid
credential
• In response body makes the Boolean value as true
RESULT: Normal user gets admin privilege.](https://image.slidesharecdn.com/brokenauthnauthz-180216051724/85/Broken-Authentication-authorization-17-320.jpg)
Ad
More Related Content
What's hot (20)
Similar to Broken Authentication & authorization (20)
Ad
Recently uploaded (20)
Ad
Broken Authentication & authorization
- 1. Broken Authentication & Authorization - Sarwar Jahan M. Disclaimer: All the views/data presented are my own and do not reflect the opinion of my current/past employer.
- 2. Who am I Sarwar Jahan M. AppSec Engineer at • Secure Code Review|Web and Mobile App Security|Threat Modelling • Synack & Bugcrowd leaderboard: Top 10 researchers (2016) • Spoken at: n|uCon ’17 [email protected] +91 77 9597 8228 https://in.linkedin.com/in/sarwarjahanm @sarwarjahanm
- 3. Outline • Authentication? • Authorization? • Case Studies – Authentication Bypass • Case Studies – Broken Authorization and Privilege Escalation • Remediation • Q/A
- 9. Case 1: Misuse of Auth-token Login Scenario: • Valid Credential => Login status=Success & Auth-token returned in response • Wrong credential => Login status=Failed & blank Auth-token returned Attack Scenario: • Attacker (user) submits valid credential. • Intercepts the 1st Login response, copies the Auth-token & drops the response. • Sends login request with Target UserID+wrong Password. • In response, sets Login status=Success & Adds his own Auth-token value. RESULT: Attacker gets access to Victim’s account!
- 10. Case 2 – Cookie manipulation Login Scenario: User-ID in session Cookie • Successful login => App sets session cookie->user-ID (numeric value) Attack Scenario: • Attacker (user) logs in to application. • Using any cookie editor, replaces the user-ID value in cookie with that of a victim & refreshes the page. RESULT: Attacker gets access to Victim’s account!
- 11. Case 3 - Session Invalidation Login Scenario: • Multi-login allowed & Session not expired after Password reset (>3 months). Attack Scenario: • Suppose a user identifies that the account is compromised & changes the password • The active session still remains active and there was no way to invalidate the attacker’s session RESULT: Once Compromised, attacker gets lifetime access of Victim’s account.
- 12. Case 4 – Account takeover by Forgot Password functionality Password Reset Scenario: • Forgot password page gives option to select recovery option (OTP/email). • Part of the options are masked with asterisk(*). Attack Scenario: • Attacker provides victim’s user ID in forgot password page. • Selects any recovery option & using proxy tool can see and modify the OTP/email option value in request RESULT: Attacker receives recovery OTP/email and compromises the victim account
- 13. Case 5 – Authentication bypass in Mobile App Login Scenario: • On successful login, user session was stored in local /AppData/ folder (sqlite db). Attack Scenario: • After analyzing the sqlite db, it was observed that the stored session is nothing but triple encoding of the username in the format [{username}] • Attacker encodes the victim’s username thrice and pushes in the device’s AppData folder. • Opens the App in device. RESULT: Attacker gets logged in to victim’s account
- 14. Case 6 – Bypass OTP & Transfer Money from Mobile Wallet WebService Calls: • 1st call: UserID+Registered_Mobile_No => OTP sent to registered mobile number • 2nd call: Recipient+Amount+OTP => Transfer money • UserID+wrong_Mobile_No => Proper Error message • Recipient+Amount+wrong_OTP => Transaction unsuccessful with proper Error message Attack Scenario: • UserID+wrong_Mobile_No with symbol ~ => error message reveals Registered_Mobil_No • Initiate valid call to generate OTP (OTP sent to Victim’s mobile so attacker doesn’t have the OTP) • Recipient+Amount+wrong_OTP with symbol ~ error message reveals actual OTP • Recipient+Amount+retrieved OTP => Transaction Successful RESULT: Forcing Step-by-step error, Attacker debits money from victim’s bank account
- 15. Case 7 – Extracting credentials by SQLi Observation: • All input form-fields seemed secure from SQLi. • After login, the application shows Last Login Time. • Found out that the time stamp was fetched from client system & sent with login request. Attack Scenario: • After multiple trials, successfully executed a union based SQL injection payload in the timestamp parameter. RESULT: Attacker fetched credentials of all the users from the database.
- 16. Case Studies Broken Authorization and Privilege Escalation
- 17. Case 1 - Boolean based privileges Application Design: • Application has only two privileges – Admin & normal user. • Keeps track of privilege by Boolean parameter [isAdmin/Admin/SuperManager]=[true/false]. • Admins have additional content which are unavailable for normal user. Attack Scenario: • Attacker who is a Normal low privilege user logs in with valid credential • In response body makes the Boolean value as true RESULT: Normal user gets admin privilege.
- 18. Case 2 – Role based privileges Application Design: • Application has more than two privileges. • Keeps track of privilege by integer numbers (e,g, role=0|1|2) or Constant Strings (e,g, role=Manager|Admin|user). • Roles stored in cookie. Attack Scenario: • Attacker logs in as low privilege user. • Edits the cookie and changes the role value RESULT: Attacker escalates the privilege.
- 19. Case 2.1 - Design Flaw – Low priv user updates his role Application Design: • The PeopleManager (role=1) can create/edit other users with view-only role (role=2). Only super admins (role=0) can change the role of other users or delete users. PeopleManager also cannot edit his own account. Attack Scenario: • While creating a new user, PeopleManager can use proxy tool and create new users with admin priv by changing role parameter to 0. • While editing other user’s details, PeopleManager replaces the userID with his own, adds “role” parameter to the request and sets the value to 0 RESULT: Low Privilege user updates his role to Super-Admin
- 20. Case 3 - GUI Based/Client-side privilege enforcement Application Design: • Based on different roles, the application disables/hides privileged features from low privilege users E,g, Disabling/Hiding HTML elements Attack Scenario: • Using browser dev tool (F12), attacker can inspect the elements and remove the rules enforced on the basis of roles. Thus can escalate the privilege and bypass the GUI Based/Client-side privilege enforcement RESULT: Attacker escalates the privilege and perform disabled/hidden operations.
- 21. Case 4 - IDOR to High Priv. pages, Access High Privilege functions Application Design: • High privileged pages are removed from the view for low privileged users. • Low privilege users are not provided access to sensitive/high privilege functions/features. Attack Scenarios: • Attacker either guess or finds out the high privileged pages names/references and calls the high privileged pages directly. • Attackers uses Proxy-tool and calls the high privilege function by name which they are not having access. • Because of Missing function level access control, it was possible to call and execute high privilege functions. RESULT: Attacker gets access to high privileged pages. Low privilege attacker executes High privilege function.
- 22. Case 5 - Design Flaw - user sends SPAM mail to anyone Application Design: • Normal Users can send mails only to the Team members who are available in drop down recipient list. • Only Admins can send mails to members of different team Attack Scenario: • Using proxy tool, normal user can modify the recipient address to any non team member’s address, also he can change the sender email ID RESULT: Attacker sends mail to any non-team member person on behalf of someone else (SPAMMING)
- 23. Case 6 – Deleting project by IDOR Application Design: • A normal user who is not owner can only view a project. There is no delete option for the normal user • A user can be Normal user for one project but Admin for other projects. Attack Scenario: • Normal user views the Project and copies the Project ID from URL • Normal user himself creates a Project for which he/she becomes owner • Now for this new project delete option is available • Clicks delete and using any proxy tool replaces the ProjectID with that of previous project RESULT: Normal user deleted a Project for which he/she is not owner but a normal member Responsible Disclosure: https://hackerone.com/reports/85401
- 24. Case 7 – Injecting HTML code snippet Application Design: • Low privilege normal user doesn’t have permission to add new team members Attack Scenario: • By adding the following HTML code snippet, a normal user was able to add new team members <a class="button-link u-gutter js-manage-members" href="#"><span class="icon-sm icon-member"></span> Add Members</a> RESULT: Low Privilege normal user added New team members which he did not have privilege to do Responsible Disclosure: https://hackerone.com/reports/92050
- 25. Remediation
- 26. Remediation - Authentication Bypass Caption Check Mapping of auth-token and userID Guessable User identifier in cookie Proper Session invalidation Strong Password reset functionality Response body contains debugging error message App Data contains sensitive information
- 27. Remediation - Authorization Bypass Caption Check Map user role with session ID GUI based/Client-side privilege implementation Proper Access Control Mechanism Use IDOR Server-side validation/Business Logic validation