OAuth
•Download as PPTX, PDF•
1 like•323 views
This document discusses OAuth 2.0 and API security. It covers common use cases for OAuth such as native mobile applications, web apps with client-side API calls, and web apps with server-side API calls. It also discusses important considerations for API security including authentication, authorization, data sanitization, and working with third-party identity providers. The document provides examples of past API vulnerabilities and stresses the importance of API security. It concludes with an overview of key terminology in the OAuth and API security ecosystem such as resource owner, resource server, client application, and authorization server.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (8)
Similar to OAuth
Similar to OAuth (20)
Recently uploaded
Recently uploaded (20)
OAuth
- 1. OAuth 2.0 08 August 2015
- 2. 2 Agenda • Use Cases • Important Considerations • API Security Eco System
- 3. 33 Use Cases
- 4. 4 Use Cases • Native Mobile Application • Web Apps with Server Side API Calls • Web Apps with Client Side API Calls API INTERNAL SYSTEMS WEB SERVERS WEB APP1 WEB APP2 MOBILE APPS API GATEWAY
- 5. 5 Native Mobile Applications • Long Lived Access • API Support • Physical Security Breaches • Ease of Use
- 6. 6 Web Apps with Client Side API Calls • API Support • Short lived Session • API Centric Architecture
- 7. 7 Web Apps with Server Side API Calls • API Support • Short lived Session • Complex Architecture
- 9. 9 Security • Authentication is not Authorization • Authorization decoupled from Authentication • API based Security • Data Sanitization • 3rd Party IDP • 3rd Party Client (Resource Consumer) • Added Security – MFA, Biometric etc
- 10. 10 APIs – A soft underbelly? Security vulnerabilities related to APIs
- 12. 12 iCloud
- 13. 13 API Security 18th Aug '13 - (yes, 2013!) Initial contact made with vendor. After a few e-mails back and fourth their reasoning was legacy code and they'll "get right on it". 26th Sep '14 - Follow up e-mail. Issue still not resolved. ETA "before Christmas" 5th Jan '15 - Vulnerability still exists with ample amount of time given to vendor to fix the issue. Bad stories continue…
- 14. 14 Moonpig API Vulnerability GET /rest/MoonpigRestWebservice.svc/addresses?&customerId=5379382&countryCode=9424 HTTP/1.1 Authorization: Basic aXBjiS5lOk1vb25QHjimvF58DEw Host: api.moonpig.com Connection: Keep-Alive <ArrayOfCustomerCreditCard xmlns="http://schemas.datacontract.org/2004/07/Moonpi g.Model.CustomerAttributes.Accounting" xmlns:i="http://www.w3.org/2001/XMLSchema- instance"> <CustomerCreditCard> <CardType>VISA</CardType> <CustomerId>11466749</CustomerId> <ExpiryDate>12/18</ExpiryDate> <LastFourDigits>5993</LastFourDigits> <NameOnCard>Mr X XXX</NameOnCard> <TransactionId>5983632541-1/TransactionId> </CustomerCreditCard> </ArrayOfCustomerCreditCard> { "Address": "xxxxxxrnxxxxxxxrnxxxxxxx", "AddressBookId": 414628930, "AddressType": "CustomerAddress", "AddressTypeId": 1, "Anniversary": null, "Birthday": null, "BuildingName": null, "BuildingNumber": null, "Company": "Test", "Country": "United Kingdom", "County": "London", "Custom1": null, "Custom2": null, "Custom3": null, "Custom4": null, "Custom5": null, "CustomerId": 0, "Deleted": false, "DeliveryInstructions": null, "EmailAddress": null, "FacebookId": null, "FilterChar": null, "Firstname": "Test", "Greeting": null, "LastUpdated": "/Date(147136045396670+0100)/", "Lastname": "Test", "MainAddressBookId": null, "OtherDate": null, "Postcode": " LN1 3FN", "PostcodeSystemUpdated": null, "SortByLastName": false, "Suffix": null, "TelephoneNo": null, "Title": "", "TitleId": null, "Town": "London" }
- 15. 15 More API Misuse – why throttling is needed
- 16. 1616 API Security Eco System
- 17. 17 Terminology 17 Resource Owner Resource Server Client Application Authorization Server Scope = = = = = Customer API Provider Application through which API is invoked System which can confirm the identity of customer What can I access
- 18. Overview 18
- 19. 19 Use Case – Mobile Application 19
- 22. Web Server based Apps 22
- 24. SAML based Authentication | © 2009 Axway | All24
Editor's Notes
- Credential Management – handling credentials vs token
- There are a lot of bad stories and for sure sometimes bad news is better than no news. Yahoo – private photos stolen, including private accounts of celebrities, patched the servers. But the API servers were not patched. Make sure the edge and how you give access to the backend services are secure. Snapchat – API send phone number and check Snapchat account. Scripted call attack. Useful for checking if your phonebook have snapchat. Very common functionality for social apps. White hat researcher found out about and they didnt fix the issue etc.. API management gvies you pattern of usage and also monitoring and metering. Buffer – third party API app for managing scheduled tweets and facebook updates. We in Axway use ourselves - number of issues API key stored and Oauth key were hard coded. Attackers were able to send tweets as the customer. Upshot was account owners thought their Twitter or FB account was hacked. So they changed their password. So this doesnt help because the Oauth is getting authority for the APP on your behalf. So you have to be careful how your APP providers are managing the keys. Permission based web. The backdoor that was created through one of our partners, MongoHQ who are managing our database. MongoHQ, who have been incredibly responsible and responsive regarding this also just released an update about the security breach on their blog. In short, the MongoHQ password of one of MongoHQ’s employees was stolen. That way the hackers logged into the main admin dashboard of MongoHQ and were able to use the “impersonate” feature to see all of Buffer’s database information. Through that, they wrote a script to steal our social access tokens and post spam messages on behalf of our users. Brussels Airlines - Oauth access tokens were not being encrypted or stored as hashes. They were easily accessible.
- Allegedly, at the heart of the incident was a missing safeguard (called a rate limiter) that would have prevented the hackers from employing a "brute force attack" whereby an infinite number of passwords are tried for a given iCloud account until one finally works. By now, most Internet users have bumped into a rate limiter. After several incorrect user ID and password attempts, a Web site starts to treat you with suspicion. Some sites like Google's Gmail will start by using technologies like captcha to prove that you're human and that you're not a computer that's automating repeated attempts in rapid succession. Other sites will disable your account for some period of time like 10 minutes or an hour after which you can come back for another limited round of attempts. Still, other sites, particularly financial institutions, will lock the account until a human makes personal contact with a customer service representative. In Apple's case, part of the issue has to do with how users typically only have one user ID (an "Apple ID") and password -- called a single sign-on (SSO) --- for accessing the entire constellation of Apple's online services. From iTunes to iCloud, the keys to the kingdom involve one set of credentials. As far as we know, wherever these credentials can be supplied, Apple had rate limiting in place. Well, all except for at least one (allegedly); where the credentials must be supplied in order to interface with the API for Apple's Find My iPhone service. Going back to Apple's press release and depending on your interpretation of the word "breach," exploiting such a vulnerability may not technically constitute a breach. If, for example, the lack of rate limiting through the Find My iPhone API was a deliberate choice by Apple's engineers, then the hackers simply took advantage of Apple's design decision. For Apple, which was on the verge of announcing Apple Pay -- a means by which iPhone 6 users would be able to make NFC-based contactless payments at supporting merchants -- the timing could not have been worse. When it comes to handling personal payments, nothing matters more than trust. Just ask Home Depot and Goodwill; two big national brands suffering an erosion of trust after hackers gained access to the credit card data of hundreds of thousands of their customers.
- Vulnerabilties of the Mobile App expose APIs and often related Even basic mobile app developers can install a proxy and snoop the calls a mobile app is making. how to listen to API calls from apps so it‘s going to be huge. When a user of the Moonpig app connects with the Moonpig servers via the API, there should be an authentication process to make sure that the person requesting the account details is the account holder. This means that if anyone tries to tweak the code used to request the customer data, they don't end up being able to access someone else's personal data. Unfortunately, Moonpig did not have any authentication in place, meaning that anyone could tweak the "customer ID" number in the API request to gain access to someone else’s account. Knowing this vulnerability, a malicious attacker could easily write a piece of software to automatically change the customer ID over and over again and extract the personal data of 3 million people. No authentication. Customer ID number was used. You can easily tweek the ID, make the mobile api call and gain access to all customer details. Worse thing is they didnt realise the seriousness of the issue!
- Every API request is like this, there's no authentication at all and you can pass in any customer ID to impersonate them. An attacker could easily place orders on other customers accounts, add/retrieve card information, view saved addresses, view orders and much more. At this point one would usually decompile the APK and see if there are any hidden API methods but on this ocassion there's no need, Moonpig have made it easy for us. If you hit the API endpoint with an unknown method you'll get a custom 404 with a link to a help page listing every method available in their API with helpful descriptions. The help page also exposes their internal network DNS setup - but that's another story. From the help file it does seem that the API supports OAuth 2.0 authorization which would fix this vulnerability... if it was implemented in the Android client. One particular method caught my attention: GetCreditCardDetails. Surely not? I hit the method with my test customer ID and we are returned: I hit my test users a few hundred times in quick succession and I was not rate limited. Given that customer IDs are sequential an attacker would find it very easy to build up a database of Moonpig customers along with their addresses and card details in a few hours - very scary indeed.
- APIs should be used with usage in mind. Don’t let Apps go live without knowing the usage and demand. Simple controls at basic levels can avoid these situations. Protect your backend which are often being used by your existing customers on other channels. Describe what is throttling, per client, per application, per organisation etc.
- Too much delegation Data sanitization
- The implicit grant (user agent) authentication flow is used by client applications (consumers) residing in the user's device. This could be implemented in a browser using a scripting language such as JavaScript, or from a mobile device, or a desktop application. These consumers cannot keep the client secret confidential (application password or private key). The user agent flow is as follows: -The web server redirects the user to the API Gateway acting as an authorization server to authenticate and authorize the server to access data on their behalf. -After the user approves access, the web server receives a callback with an access token in the fragment of the redirect URL. -After the token is granted, the application can access the protected data with the access token.
- The authorization code flow is as follows The web server redirects the user to the API Gateway acting as an authorization server to authenticate and authorize the server to access data on their behalf. After the user approves access, the web server receives a callback with an authorization code. After obtaining the authorization code, the web server passes back the authorization code to obtain an access token response. After validating the authorization code, the API Gateway passes back a token response to the web server. After the token is granted, the web server accesses the user's data.