Zoals ze in de Bijbel zo mooi zeggen: "wie zonder zonde is, werpe de eerste steen". Ik ben bang dat die steen dan nooit gegooid zou worden, want ik weet wat OWASP is, maar ik heb er de afgelopen jaren ook niets aan gedaan. En dat terwijl ik weet dat ik dit wel zou moeten doen. Want in ons beroep als "developer" is het programmeren eigenlijk meer naar de achtergrond geschoven en is security steeds belangrijker geworden. Vroeger, met de inbelmodems liep het niet zo'n vaart, maar nu kan iedereen wereldwijd "jouw site/sites" onder vuur nemen om te kijken of "ze er doorheen kunnen komen". Als je geluk hebt, is het een ethical hacker die je laat weten dat er wat aan de hand is met je site en dat je het eigenlijk zou moeten fixen. Als je pech hebt staan al je klantgegevens straks online en heb je een datalek te pakken.
Ik zeg wel dat security belangrijker geworden is, maar de tijd die er in gestoken wordt is vaak nog te weinig. De eerste reactie op een mailtje van een Indiase gast die mailt: "I found a vulnerability on your site. Could you send me a reward?" is vaak een grote zucht en "daar is er weer één". Terwijl we eigenlijk blij zouden moeten zijn dat de bevinding netjes bij ons gemeld wordt. Het komt doordat onze dagen gevuld zijn met werk. En in mijn geval in de avonduren met hier blogs delen en 100-en andere dingen die ik nog moet/wil doen. Ik zou nog een keer wat beter naar Knock-out (Javascript framework) kijken, maar nu las ik ergens dat dit verouderd is en je dus beter naar andere frameworks kunt gaan kijken. Je had online ooit een meme staan van een jochie dat huilt en Tom Hanks die vraagt wat er aan de hand is, of hij getroffen is door corona en het jochie reageert met "ik ben IT-er", waarbij Tom Hanks 'm troostend in zijn armen sluit. Want waar in de corona-pandemie veel mensen minder konden werken, was het in onze sector business as usual, doorwerken dus. Die rust hebben wij niet gehad.
In mijn vakantie heb ik een schema gemaakt met wat ik eigenlijk elke week elke avond wil/zou moeten doen. Zo heb ik op maandagavond 1 uur ingepland voor Security zaken. Dat kan van alles zijn. Ik heb hier nog een dik boek "Official (ISC) Guide to the CISSP CBK en bijbehorende studiegids, maar ik heb zonet eerst even de security-headers van een website die ik onderhoud bijgewerkt: link elmah-tips, waardoor securityheaders 'm nu weer een A-score geeft. En ik heb nog even gezocht wanneer ik op OWASP gestuit ben.
De eerste keer dat ik van OWASP hoorde was in 2015 tijdens de Holland Webweek in Groningen: link. Vervolgens in het boek Secure by Design (logisch) in 2020: link. In aflevering 272 van een podcast van Scott Hanselman en in podcast 711.
Naast het feit dat ik toen wat tools en linkjes heb genoteerd, heb ik nog geen tijd vrijgemaakt om daarmee aan de slag te gaan. Ik ga kijken of ik dat elke maandag in mijn "security-uur" mee kan nemen.
Voor dit artikel maak ik het overzicht van de "top 10". Ik had ergens genoteerd dat die 1x in de 3 jaar bijgewerkt werd, maar dat zal vermoed ik wat vaker gedaan worden. Want op Github zag ik een versie waar 2017 met 2021 wordt vergeleken ( link ), maar op de website zie ik een artikel over "een update van juli 2023": link. Je vindt daar een link naar de lijst: en die staat hier.
Laat ik ze hier even stuk-voor-stuk proberen te vertalen/benoemen. De conclusie mag wel zijn dat ik hier geen SQL-injection, XSS-zaken meer zie, maar alleen maar API zaken. Niet dat SQL-injection verdwenen is, maar omdat we steeds meer met API's werken, wordt het interessanter om die te "misbruiken":
API1:2023 - Broken Object Level Authorization
We gebruiken steeds meer API's. Niet alleen om externe partijen toegang te geven tot onze data, maar ook op de eigen website. Want het is zo makkelijk om de "back-end developers" de code te laten uitwerken, terwijl "front-end" alleen die API's maar hoeven aan te roepen en zich kunnen richten op design en de gebruiksvriendelijke interactie om data heen-en-weer te sturen. In het request worden ID's gestuurd, vaak is dit een integer of GUID-waarde. Maar als "iemand" die waarde aanpast, controleer je binnen je API endpoint wel dat degene die het verzoek stuurt het recht heeft om die actie op dat ID uit te voeren? Dat dit security-issue op 1 staat komt omdat het een redelijk simpele actie is om "foute data te sturen" en de impact hoog kan zijn. Meer informatie staat hier (met voorbeelden): https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/
API2:2023 - Broken Authentication
Authenticatie-zaken in websites worden vaak foutief of onvolledig uitgevoerd, waardoor hackers in kunnen loggen onder een ander account, zaken aan kunnen passen. We zien een voorbeeld van hoe een graphql, waar maximaal 3 inlogacties per minuut uitgevoerd kunnen worden, kan worden omzeild door veel requests in 1 batch aan te leveren. Hoe als je maar een token hebt een e-mailadres aan kunt passen (zonder nog een keer het huidige wachtwoord ter bevestiging in te voeren bijvoorbeeld). Meer informatie staat hier https://owasp.org/API-Security/editions/2023/en/0xa2-broken-authentication/ en daar heb je ook meteen een link naar de authenticatie-cheatsheet: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
API3:2023 - Broken Object Property Level Authorization
Dit is een combinatie van 2 eerdere bevindingen, API3:2019 Excessive Data Exposure en API6:2019 - Mass Assignment, waarbij via de API "te veel eigenschappen terug gegeven worden" en het ook mogelijk is om die gegevens nog eens aan te kunnen passen. Bijvoorbeeld een ID van de persoon die de order heeft goedgekeurd, als klant hoef je dat niet te weten en als je dat dan ook nog aan kunt passen, dan is je data onbetrouwbaar geworden. Meer informatie staat hier https://owasp.org/API-Security/editions/2023/en/0xa3-broken-object-property-level-authorization/
API4:2023 - Unrestricted Resource Consumption
Ongelimiteerd gebruik van bronnen, dat kan nooit goed zijn. We zien voorbeelden van een wachtwoord-reset, waarbij een SMS naar de gebruiker wordt gestuurd (a 5 cent per call), als je een batch-scriptje laat draaien loopt dat gauw in de papieren. En een voorbeeld van het uploaden van bestanden, waarbij ingesteld is dat er tot 15 GB zaken in cache komen te staan. Een gebruiker krijgt het voor elkaar om een bestand van 18 GB te uploaden. Alle cliënts gaan het bestand binnen halen, er is geen monitoring op kosten van de dienst, dus aan het eind van de maand is de rekening die anders 13 dollar was verhoogd naar 8.000 dollar... Meer informatie staat hier https://owasp.org/API-Security/editions/2023/en/0xa4-unrestricted-resource-consumption/
API5:2023 - Broken Function Level Authorization
Het lijkt wel een beetje op API2. Maar het gaat hier om endpoints die je mag aanroepen (met een GET), maar waarbij de kwaadwillende een DELETE of POST probeert om te kijken of je zo data kunt aanpassen/toevoegen/verwijderen. En dat in veel gevallen er geen validatie plaatsvindt.. Meer informatie staat hier https://owasp.org/API-Security/editions/2023/en/0xa5-broken-function-level-authorization/
API6:2023 - Unrestricted Access to Sensitive Business Flows
Ongelimiteerde toegang tot business-flows. Dit zijn zaken zoals een online aankoop, de flow om een reactie op een website te plaatsen. Voorbeelden die gegeven worden is dat iemand de volledige voorraad van een product opkoopt en dan zelf ergens anders voor een hogere prijs doorverkoopt. Een andere is een luchtvaartmaatschappij, waarbij geen annuleringskosten voor een vliegtuig hoeft te betalen. De hacker koopt 90% van de tickets en een paar dagen voor vertrekt annuleert hij ze allemaal. De luchtvaartmaatschappij moet wel afprijzen om het vliegtuig nog een beetje gevuld te krijgen, dus de hacker kan dan een veel voordeliger kaartje kopen. Meer informatie staat hier https://owasp.org/API-Security/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows/
API7:2023 - Server Side Request Forgery
Je zou met een post altijd een token mee moeten sturen, de server valideert dan wat je verstuurd hebt. Klopt dat niet, dan is dat Request Forgery. Hier gaan we een stap verder. Jij doet een request naar de server en de server doet een request naar een andere server om iets te doen. Meer informatie staat hier https://owasp.org/API-Security/editions/2023/en/0xa7-server-side-request-forgery/
API8:2023 - Security Misconfiguration
Algemene fouten in security. Waarbij bepaald verkeer niet via HTTPS gaat. Waarbij de cache-control niet gezet wordt, waardoor "private chat" zaken in cache op je computer kunnen komen. Meer informatie staat hier https://owasp.org/API-Security/editions/2023/en/0xa8-security-misconfiguration/
API9:2023 - Improper Inventory Management
Een combinatie van dat niet duidelijk is waar een API voor dienst, wie toegang mag hebben en of je nu op test, acceptatie of productie zit en als er een flow met "gevoelige informatie" is waarbij niet duidelijk is waarom die flow er is en er niet inzichtelijk is wat er gedeeld wordt. Meer informatie staat hier https://owasp.org/API-Security/editions/2023/en/0xa9-improper-inventory-management/
API10:2023 - Unsafe Consumption of APIs
Dit is een goeie. Je moet altijd wantrouwend zijn met user-input. Daar valideren we altijd op. Maar valideer jij ook wat jij terug krijgt van andere API's die je aanroept? Als die gehackt is en je krijgt "foute data binnen", ga je dan voor de bijl? Meer informatie staat hier https://owasp.org/API-Security/editions/2023/en/0xaa-unsafe-consumption-of-apis/