One Article Review
| Source |  AlienVault Lab Blog |
|---|---|
| Identifiant | 5489969 |
| Date de publication | 2022-06-20 10:00:00 (vue: 2022-07-01 11:17:02) |
| Titre | API attack types and mitigations |
| Texte | This blog was written by an independent guest blogger. Stop, look, listen; lock, stock, and barrel; "Friends, Romans, Countrymen..." The 3 Little Pigs; Art has 3 primary colors; photography has the rule of thirds; the bands Rush and The Police; the movie The 3 Amigos. On and on it goes - "Omne trium perfectum" – “Everything that comes in threes is perfect.” While this article doesn’t provide perfection, we’ll focus on the top three API vulnerabilities (according to OWASP). OWASP’s international standard is important to read because it’s not only developed by professionals worldwide, but it’s also read by the threat actors who will take advantage of those vulnerabilities. OWASP determines the risk of APIs based on the level of the API vulnerability's Exploitability, Weakness Prevalence, Weakness Detectability, and Technical Impact. Therefore, the API Top 10 are in order of OWASP's own risk methodology. Their risk method doesn't consider the chance of materialization or the impact - that's left up to each business. But these three are great places to start because they've affected large companies such as Peloton in 2021. 1. API1:2019 Broken Object Level Authorization (BOLA) In this vulnerability, aka BOLA, APIs expose endpoints that handle object identifiers, which in turn allows visitors access to numerous resources. This attack is like Insecure Direct Object Reference (IDOR), where applications use user-supplied credentials to access objects. In the API sphere, BOLA is more accurate than IDOR – the problem is broken authorization over a sequence of API calls. Every call to a data source that uses user-provided input should include object level auth checks. Here’s a simple example of how this works. An API call has the following path: /customers/user/bob/profile. An attacker will attempt various names in place of “bob” to see what can be accessed, such as: /customers/user/alice/profile /customers/user/john/profile Even if the name is replaced with long mixed characters, if those character sequences are sequential or otherwise guessable, the problem remains and is vulnerable. Mitigation Implement an authorization mechanism that relies on user policies and hierarchy. Use an authorization mechanism to check if the logged-in user has authorization to perform the requested action on the record in every function that uses an input from the client to access a record in the database. Use random and non-guessable values for record IDs. Evaluate the authorization checks. 2. API2:2019 Broken User Authentication When authentication mechanisms are implemented improperly, attackers can compromise authentication tokens or exploit implementation flaws by assuming other users’ identities. A prominent example of this vulnerability is the 2021 Parler breach. Other factors came into play in the whole breach, but at least one endpoint did not require authentication, giving anyone who found it (and someone did) unhindered access to images. Mitigation Use industry-standard authentication and token generation mechanisms (and read the accompanying documentation). Be aware of all the possible API authentication flows in the product or service (mobile/ web/deep links that implement one-click authentication/etc.). Treat “forget password” endpoints as login endpoints in terms of brute force, rate limiting, and lockout protection. Use the OWASP Authentication Cheat Sheet. Implement multi-factor authentication wherever and whenever possible. Check for weak passwords. API keys should be used for clie |
| Notes | |
| Envoyé | Oui |
| Condensat | “everything “forget “what /customers/user/alice/profile /customers/user/bob/profile /customers/user/john/profile 100 2021 access accessed accompanying according accosted accurate acknowledging acquainted action active actors addressed advantage affected all allows along also always amigos amount and/or another any anyone api api1:2019 api2:2019 api3:2019 apis app appearance appearing applications applying are art article as: ask aspect aspects assuming attack attacker attackers attempt auth authentication authentication/etc authorization aware bands barrel; based because become before being better blog blogger bola both bracelets breach broken brute business but call calls came can capture challenge chance character characters cheat check checks click client colors; comes common companies compromise concept confident confidential confidently consider consideration considered contain countrymen credentials crossing customer data database defense depend designers detectability determine determines developed developers did difficult direct display distracted documentation doesn doesn’t doing each efforts eliminate endpoint endpoints engaged engineering engineers etc evaluate even every examine example excessive exploit exploitability expose exposure factor factors favor filtered filtering flaws flow flows focus focusing following force former found free friends from function fundamental generation get giving goes great greater greatly guessable guest guidance handle hard harder has have headway here’s hierarchy high how identifiers identities idor ids images immediate impact implement implementation implemented important improperly include increase independent industry input insecure international issues it’s items jewelry job keys know known knows large lazes least left level like likely limiting links listen; lists little lock lockout logged login long look looking maintenance major making management materialization may means mechanism mechanisms method methodology minimum missed mitigation mitigations mixed mobile/ model more move movie much multi name names necessary necklaces needs negligence never non not nothing numerous object objects omne one only order organization organizations other otherwise over owasp owasp’s own parler password” passwords path: peloton perfect perfection perfectum perform phone photography pigs; pii place places play police; policies poses possible postman posture presents prevalence prevents primary privacy problem product professionals projects prominent protection provide provided provides purse random rate reaching read record reduced reference relies remains replaced requested require resources responses reveals review risk roadmap romans rule rush secure securing security see self sensitive sensitivity sequence sequences sequential service sheet should side simple slumps solve some someone source sphere standard start staying stock stop such supplied take tall target targets tasks teams technical terms test testing than that then there therefore these they think thirds; those threat threats three threes time token tokens top toward treat trium trust turn type types unhindered use used user users’ uses using valid values various visible visitors vulnerabilities vulnerability vulnerable walks way we’ll weak weakness web/deep what when whenever where wherever which who whole will wire won’t works worldwide written zap |
| Tags | Vulnerability Threat |
| Stories | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.