Download to read offline
Uploaded byEduards Salnikovs
API security
An API security expert presented on common API security risks and best practices. The document discussed an API bug at Google that may have exposed over 500,000 user profiles since 2015. It then covered common causes of data breaches and costs associated with them. The rest of the document outlined strategies for securing APIs, including using standards like OAuth for authentication and authorization, and implementing controls like access logging and monitoring, and input validation. It stressed the importance of limiting data exposure and enforcing access policies and permissions.
API security
- 1. API security Do Iexpose more than I should? Eduards Salnikovs Group IT Security Day 11.10.2018
- 2. October 8, 2018 "Googleannounced it is shutting down the Google+ social network after its engineers found an API bug that might have exposed private profile data for more than 500,000 users. Google said it couldn't determine which users were impacted by this bug because the API was designed to keep logs for only two weeks. Bug might have leaked user data since 2015."
- 3. Breach causes 47% plannedattack 28% system fault 25% human factor Data breach trends 279 days average time to identify breach 67% of costs occur in the 1st year from breach Response team formation reduces costs on average by $360K $3.9 million average cost of data breach * Source: IBM/Ponemon Cost Of Data Breach Report 2018
- 4. * Growing digitalizationdemands, via ProgrammableWeb Changing landscape of data protection… • 1994: Get me a domain and a page • 2000: Make my pages interactive • 2006: Facebook goes public • 2008: Whatsapp • 2010: Integrate APIs with developers • 2018: PSD2 and GDPR
- 5. 5 ...and shifting boundariesin architecture Data owners Data consumers Machine users and data consumers Private or Public Authorization and data segregation Authentication Authentication Future state Local Applications Global API Platform
- 6. API common threatsand security risk exposure Broken function level authorization Excessive data exposure Lack of resources and rate limiting Broken object level authorization Broken user authentication Mass assignment Security misconfiguration Injection Improper assets managmeent Insufficient logging and monitoring * Source: OWASP Ten Most Critical API Security Risks in 2019
- 7. Traditional four linesof API defence 7 Do I expose more than I should?
- 8. Federation: Authentication layeron top of OAuth Open industry standard: OpenID Connect Separation of user from the system requiring access Allowing userstobeauthenticatedbyrelying parties Eliminating theneedforlocalapploginfunctionality Allowing userstologintomultiplesiteswithoutseparateidentityforeach
- 9. Authentication: Answering andverifying ‘Who you are’ Open industry standard: OpenID Connect Identity validation as presented in: TYPE IAcceptingproofofidentitygiven byacredibleperson/entity TYPE IIComparingtheattributesoftheobjecttowhatisknownaboutit TYPE IIIRelianceonanymiscexternalaffirmations
- 10. Authorization: Answering andverifying ‘What can you access’ Open industry standard: OAuth With fine grained segregation of rights as: XACML modelorsimilarimplementationi.e.OracleEntitlementsServer Databaseobjectlevelaccesssegregationi.e.OracleVirtualPrivateDatabase Anyothercustomsolution
- 11. Delegation: Open industrystandard: OAuth With access delegation problems solved: Reductionofpasswordsharingbetweenusersandthird-parties Easinessofaccessrevocation
- 12. OAuth access controlin a nutshell 12 Resource owner End user Client Mobile app, Web site... Resource Server Service that exposes data through API Authorization server OAuth Security Token Service Access token Refresh token
- 13. 13 Reference architecture helperassets Access Control Translation Traffic Management Security and Encryption Logging and Monitoring API Catalogue Automatic Build and Test Artifact Repository Runtime Management API Management Key, Token and Certificate Management Design Center Security threat protection DevOps and Discovery Runtime Developers Apps
- 14. Related activities todevelopment lifecycle 14 Design Development Testing Maintenance • Sensitive data handling* • Least priviledge principle • Encryption and signatures • Best practices • Static analisys • Data input validation • Error handling • Type checking • Security testing • Dynamic analisys • Penetration testing • Data segregation • OWASP • Logging and auditing • Custom error messages • Quotas and throttling • IP Whitelisting • One-way, two-way TLS * See next slide
- 15. What should beconsidered as sensitive data • Identification data: personal identifiers, etc. • Personal characteristics: personal details, habits, personality, character, race,.. • Family circumstances: family details, current marriage, marital history,.. • Social circumstances: accommodation, professions, immigration, lifestyle,.. • Employment details: currently employment, employment history,.. • Health: physical & mental health record, disabilities, sexual life,.. • Financial details: income, debts, loans, property,.. • Other data: reference to records or manual files, criminal records,.. 15
- 16. API Implementation securitychecklist Create API key for data consumer Enable logging and auditing with sensitive data scrambling Apply IP whitelisting and throttling where applicable Enforce developer role and permission policy Ensure use of one-way/two-way TLS Mask and encrypt data at-rest and in-transit Inform data owners of new data consumers and exposure
Editor's Notes
- #4 SPEAKER: As many of you have pointed out – our values provide us with a kind of internal compass that helps us understand how to behave in different situations and make decisions, both internally and externally.
- #5 SPEAKER: Welcome to the workshop! Introduce yourself and all other facilitators. If the participants do not know each other, provide some extra time for brief introductions. Before we get started, we like to take a few minutes and set the stage by listening to a short message from our CEO, Mikael Ericsson. Then show the short film from Michael.
- #7 API Security Chapter 12, IT Security Instruction: Strong authentication (two-factor-authentication) shall be used to access confidential and restricted data if these are made available through a web interface or API over an open network. Chapter 31, IT Security Instruction: For externally accessible services, secure communication channels based on strong ciphers suites as defined by NIST shall always be used. Use of weak ciphers is prohibited, to ensure high resistance to cryptanalysis by unauthorized parties. An Application Programming Interface (API) is basically a set of requirements that govern how applications can interact with each other. In the 24/7 connected world that we live in API’s have become a major component in Intrum’s business strategy. Unfortunately the number of reported breaches in various industries through insecure API’s are plenty and new ones are reported almost weekly. Required Security controls depend on several parameters and may not be the same for all API’s. An API that is used to provide stock prices may not require the same level of security as and API that is used for uploading or modifying debtor information. The starting point for each API assessment should however be the expectation that EVERYONE WANTS OUR DATA. This guideline document is not meant to provide a mandatory level of security for all API’s, it does however provide a list of components that should be considered. See the IT Security instructions for more details about each item to determine under which circumstances a control is mandatory. Authentication (who?) and Authorization (What): The API must have a way to authenticate and authorize the client. The client in this context is the user, service, script or similar which initiates the API Call). For web authentication this is commonly done through a dialog which asks the user to submit a username and password and additional factors are required (Multi-Factor-Authentication). API’s often use some sort of access token (preferred method). Authorization should be based on the least privilege principle (e.g. if the client is only authorized to perform a get request it should not be able to perform a POST). Stick to best practices and recognized standards like, OAuth 2.0, JSON Web Tokens. (NOTE: if OAuth 1.0 is currently in use this is not a problem but since OAuth 2.0 is easier to implement and less error prone this is considered to be a better option moving forward). Several large cloud providers have stopped supporting version 1.0 already. Basic authentication is strongly discouraged but if it must be used and the previous options are not possible then it should be used together with Hash-based Message Authentication Code (HMAC) and an arbitrary number (nonce) to reduce the risk from a Replay Attack. The nonce can for instance be a timestamp which also provides the ability to ignore any messages older than a predefined time window. Set expiration periods on tokens. Expiration periods depend on several factors but should be as small as possible. Whitelisting and filtering Consider IP whitelisting if this is possible. IP whitelisting would only allow connections from trusted IP’s and rejecting all others. Use robot.txt file to avoid indexing by search engines like google and Bing. Data Validation Input validation. All input should be validated based on string, length, content. Invalid input should be logged and be rejected for processing on the back-end server Output validation. Any output should be validated based on string, length, content. Invalid output should be logged and dropped. HTTP Security Headers Use HTTP Security headers to prevent common attacks like clickjacking, cross-site-scripting. Best practices and options are explained here. Error messages Use customized error messages and avoid leaking of technical or other information that can be used by an attacker to prepare a more sophisticated attack. Encryption and signatures. At a minimum the transport layer should be encrypted for any information that may be considered as sensitive (PII, credentials, etc.). Only use strong cryptographic controls (Strong TLS and strong ciphers). Encryption and Signatures are often used in conjunction; the signature could be encrypted to only allow certain parties to validate if a signature is valid - or the encrypted data could be signed to further ensure that data is neither seen nor modified by unwanted parties. See more on HMAC here. Use HTTP Strict Transport Security (HSTS) to force HTTPS. This will force any further communication between the client and the server is requested via HTTPS. Only use certificates from an authorized and recognized Certificate Authority (Internal applications may use certificates from an internal CA, Self-signed certificates are not trusted by default by all clients and should be avoided) Understand which vulnerabilities may be applicable. There are many different attacks with different methods and targets (see threat modeling and OWASP/SANS lists earlier in this document) Network / OS / Driver: issues in the operating system and network components (e.g. buffer overruns, flooding with sockets, DOS attacks) Application layer: issues in the hosting application server and related services (e.g. message parsing, session hijacking or security misconfigurations). API / component: functional issues in the actual API (e.g. injection attacks, sensitive data exposure, incomplete access control). API’s must not be published with known vulnerabilities (See paragraph 6.7 in this document and chapters 17 & 29 of the Group IT Security Instructions) Use Quota’s and Throttling. Quota’s (e.g. 5MB per day or 1 message per day) and throttling (e.g. 5 connections per source IP, or 20 messages per 30 seconds) can be used to protect against (D)DoS attacks and changes is traffic behavior (e.g. thousand instead of the normally observer 5 per minute) may indicate a brute-force attack and require investigation. Violations should result in an automated lockout of the IP/User and should only be allowed again after confirmation. Independent security assessment. Let the API be assessed by a trained resource (internal or external). The resource should use a combination of vulnerability scanning and penetration testing to do an independent security assessment before the API is published. The assessment should include a combination of automated and manual testing against the OWASP top 10 vulnerability list. Use HTTP method whitelisting. Only allow relevant HTTP methods (e.g. if the API should only be used for GET requests then whitelist this methods and use a default deny for all other methods) Logging & auditing. A trace log should be available so access attempts and activities are logged and can be traced back to the source. Available options may differ based on the type of API: Identifier (username, CustomerID, ServiceID, etc.). Source IP Method (get, update, list, etc.). Timestamp Allowed or rejected status Service-type (SOAP, JSON, XML), User Agent. Etc. Consider the use of security tools and API gateways. Using security tools or an API gateway will allow for streamlined API security controls and centralized management of the controls mentioned above (cryptography, throttling, logging, filtering, etc.). Group IT is working on the implementation of an API gateway. The organization should align with the enterprise architect to determine requirements and responsibility boundaries.
- #9 SPEAKER: We have three primary objectives today: Firstly, we want to create a shared understanding of our brand identity and how it all fits together. We also want to dig deeper into our values and discover what they mean in our everyday working lives. And finally, we want to inspire and build curiosity in the whole company. This is a long-term engagement process, it’s not over when we are done here today – it’s actually only just begun. But we have to start somewhere!
- #10 SPEAKER: We have three primary objectives today: Firstly, we want to create a shared understanding of our brand identity and how it all fits together. We also want to dig deeper into our values and discover what they mean in our everyday working lives. And finally, we want to inspire and build curiosity in the whole company. This is a long-term engagement process, it’s not over when we are done here today – it’s actually only just begun. But we have to start somewhere!
- #11 SPEAKER: We have three primary objectives today: Firstly, we want to create a shared understanding of our brand identity and how it all fits together. We also want to dig deeper into our values and discover what they mean in our everyday working lives. And finally, we want to inspire and build curiosity in the whole company. This is a long-term engagement process, it’s not over when we are done here today – it’s actually only just begun. But we have to start somewhere!
- #12 SPEAKER: We have three primary objectives today: Firstly, we want to create a shared understanding of our brand identity and how it all fits together. We also want to dig deeper into our values and discover what they mean in our everyday working lives. And finally, we want to inspire and build curiosity in the whole company. This is a long-term engagement process, it’s not over when we are done here today – it’s actually only just begun. But we have to start somewhere!