Moltes organitzacions recopilen dades d'una infinitat de fonts, com els usuaris, i després les emmagatzemen a llacs de dades. Actualment, les dades ho són tot, igual que la capacitat de processar una gran quantitat de dades en poc temps.
L'ús de les dades sempre es fa a través d'APIs. Les API mantenen units tots els components de l'aplicació i els fan accessibles com un de sol per a qualsevol tipus de client, com un usuari.
Per descomptat, les API no van venir soles. L'arquitectura monolítica tradicional ha donat pas a d'altres, com ara els microserveis. Avui tot és modular. Els microserveis fan que qualsevol aplicació sigui modular per a una millor escalabilitat, més flexibilitat i menor time-to-market.
Els microserveis combinats amb les API es consideren el futur del desenvolupament de programari. Això és tan cert que OWASP va llançar el 2019 una versió adaptada a APIs del seu conegut OWASP TOP 10. Per tant, en aquest escenari, la seguretat de les aplicacions s'ha d'adaptar a aquesta nova manera de crear programari i mantenir-se al dia.
A la darrera dècada, la seguretat per a aplicacions també ha evolucionat en forma de diverses proves de seguretat automatitzades i especialitzades. Tot i això, aquesta evolució dels controls de seguretat sembla quedar-se enrere, com passa amb les anàlisis dinàmics de seguretat d'aplicacions (DAST).
DAST, un tipus guai
Lanàlisi DAST va sorgir com una eina de caixa negra "bastant" automàtica per trobar vulnerabilitats específiques en aplicacions web en un moment en què gairebé les úniques tècniques eren lanàlisi SAST i el pentesting manual. Els DAST van sorgir amb la promesa d'ajudar el pentester i cobrir alguns dels buits a les eines SAST, com ara reduir els falsos positius i el temps d'escaneig.
El procés d'execució és molt senzill: a partir de conjunts de regles predefinits, envieu sol·licituds HTTP a l'aplicació web i verifiqueu certes cadenes de text en les respostes per veure si hi ha alguna vulnerabilitat. En poques paraules, l'anàlisi DAST intenta simular un pentester.
No cal dir que hi ha un parell d'inconvenients principals:
- Falsos positius. Qualsevol nombre de falsos positius necessitaria una breu revisió després de l'escaneig, l'anomenat triatge. Aquest triatge sovint necessitaria els ulls experts d'un analista de ciberseguretat i, fins i tot per a un expert, fa un temps preciós que pot acabar alentint els passos posteriors a l'escaneig
- Temps. Els escanejats triguen temps a executar-se, generalment de 30 minuts a 2 hores, o potser dies, depenent de la mida de laplicació. A més, el temps dependrà de la bona que sigui la configuració. Com millor sigui la configuració, menys temps trigarà a executar-se. Però aconseguir una bona configuració prèvia a l'escaneig no és tan fàcil i la majoria de vegades també requereix un expert en ciberseguretat
El DAST està molt per darrere del desenvolupament de programari
La manera de desenvolupar programari ha canviat. El DAST ara se sol integrar al pipeline CI/CD i, en entorns de CI/CD, l'agilitat i la velocitat són peces clau. Qualsevol compilació i implementació no ha de durar més dun parell de minuts.
Això no passa amb les anàlisis DAST. Com ja hem esmentat, els escanejats DAST triguen temps a executar-se, es necessita temps per revisar les troballes i temps per configurar-los. Però aquests esculls no són els únics contraris a l'agilitat i la velocitat:
- Descobriment i crawling. Una de les principals característiques de les eines DAST és la seva capacitat per buscar i navegar gairebé tots els racons de l'aplicació durant l'escaneig. Aplicant algunes regles heurístiques per reescriure adreces URL i seguir enllaços, les eines DAST poden detectar i rastrejar nombrosos subdominis i seccions d'aplicacions web. Una altra versió d'aquest procés de descoberta consisteix a utilitzar proxies i recopilar tots els endpoints que s'analitzaran. Però actualment, mentre que la seguretat s'està desplaçant cap a l'esquerra a l'SDLC, aquestes característiques es podrien considerar una deficiència perquè requereixen temps. Afortunadament, la majoria de les eines DAST al llarg dels anys han inclòs la possibilitat d'especificar en diversos formats quins endpoints de l'aplicació es volen escanejar
- Els desenvolupadors usen DAST. Sota el nou paradigma DevSecOps, els desenvolupadors poden utilitzar pel seu compte algunes eines presents als pipelins, com les eines de seguretat, amb l'objectiu d'aconseguir més agilitat en procés de desenvolupament de programari. Si els desenvolupadors per si mateixos poden revisar les troballes d'una anàlisi de seguretat d'una anàlisi DAST, suposadament acceleraria tot el procés de desenvolupament. En teoria. A la pràctica, els desenvolupadors no sempre saben distingir què és un fals positiu i què no ho és, o necessiten invertir més temps per fer-ho que un expert en seguretat. Aquest escenari redueix dràsticament la tolerància als falsos positius dels equips de DevSecOps i soscava la confiança en els controls de seguretat
Finalment, el programari en si també ha canviat. Com hem dit al principi, les APIs i els microserveis són el present i el futur, i el DAST està ben adaptat per a ells:
- El DAST no identifica cap contingut generat de forma dinàmica al front-end, la qual cosa és molt comú avui dia a causa de l'ús estès de frameworks Javascript, com Angular, React, Next, JQuery, etc
- El DAST no detecta alguns tipus de vulnerabilitats habituals a les APIs, com els IDOR/BOLA, perquè per això es requereix context de la lògica de negoci de l'aplicació, com a rols d'usuari i privilegis
- El DAST també té dificultats per passar a través d'alguns murs de protecció, com ara tokens anti-CSRF i diversos mecanismes típics d'autenticació/autorització en APIs, com OAuth2, SSO i autenticació multifactor. Tot i que és possible superar algunes d'aquestes barreres, sens dubte augmentaria el temps per preparar l'escaneig, i cada aplicació necessita la seva configuració a mida
Com utilitzar DAST el 2023 i no morir a l'intent?
Arribats a aquest punt, és força temptador pensar que el DAST és inútil, però no ho és. Moltes de les deficiències anteriors es poden esmenar mitjançant l'ús del DAST d'altres maneres:
- Reutilitzar DAST per trobar resultats fàcils. Algunes vulnerabilitats són fàcils i ràpides de trobar per a qualsevol eina DAST i tenen una proporció de falsos positius raonablement baixa. Alguns exemples són les capçaleres HTTP insegures o inexistents, Cross Site Scripting o fins i tot algun tipus de SQLi
- Provar requisits de seguretat específics. Si hi ha un catàleg de requisits de seguretat, l'anàlisi DAST podria utilitzar-se per executar un conjunt molt específic de proves per verificar aquests requisits d'alt valor a moltes aplicacions
- Crear plantilles de configuració per endavant. Com ja hem esmentat, com millor sigui la configuració, menys temps trigarà a executar-se. Seria una bona idea invertir temps a preparar configuracions que es poden utilitzar per escanejar diverses aplicacions amb característiques o arquitectura similars. En fer-ho, amb una sola configuració ben feta, el temps d'execució i els falsos positius es reduirien considerablement en futurs escanejats
- Evitar escanejats complets. Escanejar tota l'aplicació podria durar molt de temps i cada pas amb pipeline de CI/CD hauria de durar només uns segons o minuts. En canvi, cal limitar l'abast de l'escaneig únicament als darrers canvis realitzats a l'aplicació
- Alimenteu el DAST amb les rutes de l'API exactes a escanejar. Si l'eina ho admet (recomanat), provar només els endpoints de l'API que es vol analitzar, com els que tenen canvis. Això permetria obtenir una cobertura d'escaneig del 100% gradualment sense alentir el procés de CI/CD
- Executar el DAST de manera asincrònica. Si l'escaneig s'inicia en una fase del cicle CI/CD i trigarà un temps, una bona opció seria simplement executar-lo sense esperar que s'acabi. Més tard, quan es completi, l'equip responsable podria revisar les troballes o fer-ne algun triatge
A banda d'això, el DAST segueix sent una eina realment útil per a qualsevol pentester, ja que és capaç de testejar (fuzz) una gran quantitat de paràmetres d'entrada en nombroses aplicacions en poc temps amb una sèrie de conjunts de regles predefinits que permetin trobar-ne molts tipus de vulnerabilitats, com ara injeccions i configuracions errònies.
Què ha de tenir una eina DAST per fer proves de seguretat a APIs
En avaluar eines DAST o similars per fer proves de seguretat en APIs, pot ser difícil saber quina eina és la millor opció, per la qual cosa a continuació es mostren alguns criteris que es poden fer servir:
- Fàcil d'integrar a un pipeline de CI/CD
- Permet escollir quin tipus d'aplicació s'escanejarà: API o web amb front-end
- Admet diversos formats d'especificació d'API per especificar les rutes exactes de l'API a escanejar: col·leccions de Postman, OpenAPI/Swagger, introducció de GraphQL, WADL, WSDL, etc.
- Permet seleccionar el tipus específic d'API que s'ha de provar: REST, GraphQL, SOAP
- Proporciona la capacitat de definir pre i post scripts per generar configuracions molt precises per detectar vulnerabilitats de lògica de negoci
Com a resum
La manera com es desenvolupa el programari ha canviat, igual que el programari en si. L'agilitat i la velocitat ara són característiques clau de qualsevol SDLC gràcies als avantatges d'utilitzar pipelins de CI/CD. Les API s'han convertit en el nucli de qualsevol component programari nou, per la qual cosa la generació d'aplicacions segures depèn de l'absència de vulnerabilitats a les API que hi ha per sota.
Les API s'han de provar i assegurar a un ritme molt ràpid i, encara que l'anàlisi DAST no és el més idoni per a això, és possible modificar la configuració dels escanejats i la forma d'integrar-los als pipelins per analitzar API millor i més ràpid.
La IA: una nova esperança
Aquest post no pot acabar sense fer esment a la intel·ligència artificial.
La veritat és que qualsevol solució DAST podria aprofitar la IA per resoldre molts dels desavantatges que shan esmentat en aquest article, i alguns més. Per exemple, es podria fer servir per millorar el procés de descobriment i navegació a través de la reescriptura intel·ligent d'URL, evitar sol·licituds duplicades o iteratives, disminuir els falsos positius, detectar vulnerabilitats complexes de la lògica de negoci...
Creieu que és possible que la IA es converteixi en el foc que reviurà al fènix del DAST?
Ernesto Rubio , Consultor de Ciberseguretat
