security testing
Com provar la seguretat de les aplicacions: tècniques de proves de seguretat de les aplicacions web i d'escriptori
La necessitat de proves de seguretat?
La indústria del programari ha assolit un sòlid reconeixement en aquesta època. En l’última dècada, però, el ciber-món sembla ser encara més dominant i impulsor, cosa que està configurant les noves formes de gairebé tots els negocis. Els sistemes ERP basats en web que s’utilitzen avui en dia són la millor evidència que TI ha revolucionat el nostre estimat poble global.
Actualment, els llocs web no estan destinats només a la publicitat ni al màrqueting, sinó que s’han convertit en eines més fortes per satisfer les necessitats comercials completes.
Els sistemes de nòmines basats en web, centres comercials, banca, aplicacions de comerç de valors no només són utilitzats per les organitzacions, sinó que també es venen com a productes actualment.
Això vol dir que les aplicacions en línia han guanyat la confiança de clients i usuaris respecte a la seva característica vital anomenada SEGURETAT.
Sens dubte, el factor de seguretat també té un valor principal per a les aplicacions d’escriptori.
Tot i això, quan parlem de web, la importància de la seguretat augmenta exponencialment. Si un sistema en línia no pot protegir les dades de la transacció, a ningú se li acudirà mai utilitzar-les. Seguretat no és encara una paraula que busca la seva definició ni un concepte subtil. Tanmateix, voldria enumerar alguns elogis sobre seguretat.
diferències entre c ++ i c
Exemples d’errors de seguretat en una aplicació
- Un sistema de gestió dels estudiants no és segur si la branca 'Admissió' pot editar les dades de la branca 'Examen'
- Un sistema ERP no és segur si DEO (operador d’entrada de dades) pot generar ‘Informes’
- Un centre comercial en línia no té seguretat si els detalls de la targeta de crèdit del client no estan encriptats
- Un programari personalitzat no té seguretat adequada si una consulta SQL recupera les contrasenyes reals dels seus usuaris
Seguretat
Ara us presento la definició més senzilla de seguretat amb les meves paraules.
'La seguretat significa que es concedeix accés autoritzat a les dades protegides i es restringeix l'accés no autoritzat' .
Per tant, té dos aspectes principals; el primer és la protecció de dades i el segon és l'accés a aquestes dades. A més, tant si l’aplicació és d’escriptori com basada en web, la seguretat gira al voltant dels dos aspectes esmentats.
Tenim una visió general dels aspectes de seguretat tant per a aplicacions de programari basades en web com per a ordinadors.
Què aprendreu:
Proves de seguretat d'escriptori i web
Una aplicació d'escriptori ha de ser segura no només pel que fa al seu accés, sinó també pel que fa a l'organització i l'emmagatzematge de les seves dades.
De la mateixa manera, les aplicacions web exigeixen, encara més, seguretat respecte al seu accés, juntament amb la protecció de dades. Un desenvolupador web hauria de fer que l'aplicació sigui immune a les injeccions SQL, els atacs de força bruta i XSS (scripts entre llocs). De la mateixa manera, si l’aplicació web facilita els punts d’accés remot, també han de ser segurs.
A més, tingueu en compte que Brute Force Attack no només està relacionat amb les aplicacions web, sinó que el programari d'escriptori també hi és vulnerable.
Espero que aquest pròleg sigui suficient i ara deixeu-me arribar al punt. Accepteu les meves disculpes si fins ara pensàveu que llegiu sobre el tema d’aquest article. Tot i que he explicat breument la seguretat del programari i les seves principals preocupacions, el meu tema és 'Proves de seguretat'.
Lectura recomanada => Proves de seguretat d'aplicacions web
Ara explicaré com s’implementen les funcions de seguretat a l’aplicació de programari i com s’haurien de provar. El meu enfocament estarà en Què i com es fa la prova de seguretat, no en la seguretat.
Eines de proves de seguretat recomanades
# 1) Aparcador de xarxa
Netsparker és una solució de proves de seguretat d’aplicacions web amb funcions d’exploració i rastreig automàtic de tot tipus d’aplicacions web antigues i modernes, com ara aplicacions HTML5, Web 2.0 i d’una sola pàgina. Fa ús de la tecnologia d’escaneig basada en proves i agents d’escaneig escalables.
Us proporciona una visibilitat completa tot i que teniu un gran nombre d’actius per gestionar. Té moltes més funcionalitats com la gestió d'equips i la gestió de vulnerabilitats. Es pot integrar a les plataformes CI / CD com Jenkins, TeamCity o Bamboo.
=> Proveu la millor eina de prova de seguretat Netsparker# 2) Kiuwan
Cerqueu i corregiu les vulnerabilitats del vostre codi en totes les etapes del SDLC.
Kiuwan compleix els estàndards de seguretat més estrictes, inclosos OWASP, CWE, SANS 25, HIPPA i molt més. Integreu Kiuwan al vostre IDE per obtenir comentaris instantanis durant el desenvolupament. Kiuwan admet tots els llenguatges de programació principals i s’integra amb les principals eines DevOps.
=> Escaneja el codi gratis# 3) Indusface WAS Free Website Malware Check
Indusface ERA proporciona proves de penetració manuals incloses amb el seu propi escàner automatitzat de vulnerabilitats d’aplicacions web que detecta i informa de vulnerabilitats basades en el top 10 d’OWASP i també inclou una comprovació de la reputació del lloc web d’enllaços, programari maliciós i comprovacions de deformació del lloc web en cada exploració.
=> Executeu una cerca ràpida de llocs web de franc
com obrir un fitxer .eps
=> Contacti amb nosaltres per suggerir un llistat aquí.
Llista de les 8 tècniques principals de proves de seguretat
# 1) Accés a l'aplicació
Tant si es tracta d’una aplicació d’escriptori com d’un lloc web, la seguretat de l’accés s’implementa mitjançant ‘Gestió de rols i drets’. Sovint es fa de manera implícita mentre es cobreix la funcionalitat,
Per exemple, en un sistema de gestió hospitalària, a la recepcionista li preocupa menys les proves de laboratori, ja que la seva feina és registrar els pacients i programar les seves cites amb els metges.
Per tant, tots els menús, formularis i pantalles relacionats amb les proves de laboratori no estaran disponibles per al paper de ‘Recepcionista’. Per tant, la correcta implementació de rols i drets garantirà la seguretat de l'accés.
Com provar: Per provar-ho, s’hauria de fer una prova exhaustiva de tots els rols i drets.
El comprovador hauria de crear diversos comptes d'usuari amb funcions diferents i diverses. Després hauria d’utilitzar l’aplicació amb l’ajut d’aquests comptes i hauria de verificar que cada funció només tingui accés als seus propis mòduls, pantalles, formularis i menús. Si el verificador troba algun conflicte, hauria de registrar un problema de seguretat amb total confiança.
Això també es pot entendre com a proves d'autenticació i autorització que es mostren molt bé a la imatge següent:
Per tant, bàsicament, heu de provar sobre 'qui sou' i 'què podeu fer' per a diferents usuaris.
Algunes de les proves d’autenticació inclouen una prova de regles de qualitat de contrasenya, prova d’inicis de sessió predeterminats, prova de recuperació de contrasenyes, prova captcha, prova de funcionalitat de tancament de sessió, prova de canvi de contrasenya, prova de pregunta / resposta de seguretat, etc.
De la mateixa manera, algunes de les proves d'autorització inclouen una prova de recorregut del camí, prova de falta d'autorització, prova de problemes de control d'accés horitzontal, etc.
# 2) Protecció de dades
Hi ha tres aspectes de la seguretat de les dades. La primera és que un usuari només pot visualitzar o utilitzar les dades que se suposa que ha d'utilitzar . Això també ho garanteixen els rols i els drets
Per exemple, TSR (representant per a la venda telefònica) d'una empresa pot veure les dades de l'estoc disponible, però no pot veure quanta matèria primera es va comprar per a la producció.
Per tant, aquest aspecte de les proves de seguretat ja s’explica més amunt. El segon aspecte de la protecció de dades està relacionat amb com s’emmagatzemen aquestes dades a la base de dades .
Més lectura = >> Què és la prova de seguretat de bases de dades
Totes les dades sensibles s’han de xifrar per garantir-ne la seguretat. El xifratge hauria de ser fort, especialment per a dades sensibles, com ara contrasenyes de comptes d'usuari, números de targeta de crèdit o altra informació crítica per al negoci.
El tercer i últim aspecte és una extensió d’aquest segon aspecte. S'han d'adoptar mesures de seguretat adequades quan es produeixi un flux de dades sensibles o crítics per al negoci. Tant si aquestes dades floten entre diferents mòduls de la mateixa aplicació com si es transmeten a diferents aplicacions, cal xifrar-les per mantenir-les segures.
Com provar la protecció de dades: El comprovador hauria de consultar a la base de dades les contrasenyes del compte d’usuari, la informació de facturació dels clients, altres dades confidencials i crítics per al negoci i hauria de verificar que totes aquestes dades estiguin desades de forma xifrada a la base de dades.
De la mateixa manera, ha de verificar que les dades es transmetin entre diferents formularis o pantalles només després d’un xifratge adequat. A més, el comprovador s'ha d'assegurar que les dades xifrades es descifren correctament a la destinació. S'ha de prestar especial atenció a les diferents accions de 'presentació'.
El comprovador ha de verificar que quan la informació es transmet entre el client i el servidor, no es mostra a la barra d'adreces d'un navegador web en un format comprensible. Si alguna d’aquestes verificacions falla, l’aplicació definitivament té un error de seguretat.
El comprovador també hauria de comprovar si es fa un ús correcte de la salaó (afegint un valor secret addicional a l'entrada final com la contrasenya i, per tant, fa que sigui més fort i difícil de trencar).
També s’ha de provar l’atzar insegur, ja que es tracta d’una mena de vulnerabilitat. Una altra forma de provar la protecció de dades és comprovar si hi ha un ús dèbil de l'algorisme.
Per exemple, atès que HTTP és un protocol de text clar, si les dades sensibles com les credencials d’usuari es transmeten mitjançant HTTP, és una amenaça per a la seguretat de l’aplicació. En lloc d’HTTP, les dades confidencials s’han de transferir mitjançant HTTPS (segur mitjançant SSL, túnel TLS).
No obstant això, HTTPS augmenta la superfície d'atac i, per tant, s'ha de comprovar que les configuracions del servidor són adequades i que es garanteix la validesa del certificat.
# 3) Atac de força bruta
Brute Force Attack es fa principalment amb algunes eines de programari. El concepte és que mitjançant l’ús d’un identificador d’usuari vàlid, el s Oftware intenta endevinar la contrasenya associada intentant iniciar la sessió una i altra vegada.
Un exemple senzill de seguretat contra aquest atac és la suspensió del compte durant un curt període de temps, tal com fan totes les aplicacions de correu com 'Yahoo', 'Gmail' i 'Hotmail'. Si un nombre específic d'intents consecutius (principalment 3) no aconsegueixen iniciar la sessió correctament, el compte es bloqueja durant un temps (de 30 minuts a 24 hores).
Com provar un atac de força bruta: El verificador ha de verificar que hi hagi algun mecanisme de suspensió del compte disponible i que funcioni amb precisió. (S) Ha d'intentar iniciar sessió amb identificadors d'usuari i contrasenyes no vàlids per assegurar-se que l'aplicació de programari bloqueja els comptes si es fan intents continus d'inici de sessió amb credencials no vàlides.
Si l'aplicació ho fa, estarà protegida contra atacs de força bruta. En cas contrari, el verificador ha d’informar d’aquesta vulnerabilitat de seguretat.
Les proves de força bruta també es poden dividir en dues parts: proves de caixes negres i proves de caixes grises.
A les proves Black Box, es descobreix i es prova el mètode d’autenticació utilitzat per l’aplicació. A més, la prova de caixa grisa es basa en el coneixement parcial de les dades de comptes i de contrasenyes i els atacs de compensació de memòria.
Feu clic a aquí per explorar les proves de força bruta de caixa negra i caixa grisa juntament amb exemples.
Els tres aspectes de seguretat anteriors s’han de tenir en compte tant per a aplicacions web com per a ordinadors, mentre que els punts següents només estan relacionats amb aplicacions basades en web.
# 4) Injecció SQL i XSS (scripts entre llocs)
Conceptualment parlant, el tema d’aquests dos intents de pirateria és similar, de manera que es discuteixen conjuntament. En aquest enfocament, el els pirates informàtics utilitzen un script maliciós per manipular un lloc web .
Hi ha diverses maneres d’immunitzar-se contra aquests intents. Per a tots els camps d'entrada del lloc web, les longituds dels camps s'han de definir prou petites com per restringir l'entrada de qualsevol script
fases del cicle de vida del desenvolupament del sistema amb exemples
Per exemple, El cognom hauria de tenir una longitud de camp 30 en lloc de 255. Pot haver-hi alguns camps d'entrada on sigui necessària una entrada de dades gran, per a aquests camps s'hauria de realitzar una validació adequada de l'entrada abans de desar aquestes dades a l'aplicació.
A més, en aquests camps s’ha de prohibir qualsevol entrada d’etiquetes HTML o script. Per provocar atacs XSS, l'aplicació hauria de descartar les redireccions de seqüències d'aplicacions desconegudes o no fiables.
Com prova la injecció SQL i XSS: El comprovador s'ha d'assegurar que es defineixen i s'implementen les longituds màximes de tots els camps d'entrada. (S) També s'ha d'assegurar que la longitud definida dels camps d'entrada no s'adapti a cap entrada d'escriptura ni entrada d'etiquetes. Tots dos es poden provar fàcilment
Per exemple, Si 20 és la longitud màxima especificada per al camp 'Nom' i la cadena d'entrada '
thequickbrownfoxjumpsoverthelazydog 'pot verificar aquestes dues restriccions.
El comprovador també hauria de verificar que l'aplicació no admet mètodes d'accés anònims. En cas que existeixi alguna d'aquestes vulnerabilitats, l'aplicació corre perill.
Bàsicament, les proves d'injecció SQL es poden fer de les cinc maneres següents:
- Tècniques de detecció
- Tècniques d’injecció SQL estàndard
- Empremta digital de la base de dades
- Explotació tècnica
- Tècniques d'invasió de signatures per injecció SQL
Feu clic a aquí per llegir detalladament les maneres anteriors de provar la injecció SQL.
XSS també és un tipus d'injecció que injecta script maliciós en un lloc web. Feu clic a aquí per aprofundir en les proves de XSS.
# 5) Punts d’accés al servei (oberts segells i segurs)
Avui en dia, les empreses depenen i col·laboren entre si, el mateix val per a les aplicacions, especialment per als llocs web. En aquest cas, els dos col·laboradors haurien de definir i publicar alguns punts d’accés entre ells.
Fins ara l'escenari sembla bastant senzill i senzill, però, per a alguns productes basats en web com el comerç de valors, les coses no són tan senzilles i fàcils.
Quan hi ha un gran nombre de públic objectiu, els punts d’accés haurien d’estar prou oberts per facilitar a tots els usuaris, prou acomodats per satisfer les peticions dels usuaris i prou segurs per fer front a qualsevol prova de seguretat.
Com provar els punts d’accés al servei: Deixeu-me explicar-ho amb el exemple de l'aplicació web de comerç de valors; un inversor (que vulgui comprar les accions) hauria de tenir accés a dades actuals i històriques sobre els preus de les accions. L'usuari hauria de tenir la possibilitat de descarregar aquestes dades històriques. Això exigeix que l'aplicació estigui prou oberta.
Per acollidor i segur, vull dir que l’aplicació hauria de facilitar als inversors el comerç lliure (segons la normativa legislativa). Poden comprar o vendre 24/7 i les dades de les transaccions han de ser immunes a qualsevol atac de pirateria.
A més, un gran nombre d'usuaris interactuaran amb l'aplicació simultàniament, de manera que l'aplicació hauria de proporcionar prou punts d'accés per entretenir a tots els usuaris.
En alguns casos, aquests els punts d'accés es poden segellar per a aplicacions o persones no desitjades . Això depèn del domini empresarial de l’aplicació i dels seus usuaris,
Per exemple, Un sistema de gestió d’Office basat en web personalitzat pot reconèixer els seus usuaris sobre la base d’adreces IP i nega establir una connexió amb la resta de sistemes (aplicacions) que no s’inclouen en el rang d’IP vàlides per a aquesta aplicació.
El comprovador ha de garantir que tots els fitxers accés inter-xarxa i intra-xarxa a l'aplicació són aplicacions de confiança, màquines (IP) i usuaris.
Per tal de verificar que un punt d'accés obert és prou segur, el provador ha d'intentar accedir-hi des de diferents màquines que tinguin adreces IP de confiança i no de confiança. Cal provar diferents tipus de transaccions en temps real de manera massiva per tenir bona confiança en el rendiment de l’aplicació. En fer-ho, també s’observarà clarament la capacitat dels punts d’accés de l’aplicació.
El comprovador s'ha d'assegurar que l'aplicació entretingui totes les sol·licituds de comunicació d'IP i aplicacions de confiança només mentre es rebutgin totes les altres sol·licituds.
De la mateixa manera, si l’aplicació té algun punt d’accés obert, el verificador hauria d’assegurar-se que permet (si cal) carregar dades de manera segura pels usuaris. D’aquesta manera segura, em refereixo al límit de mida del fitxer, a la restricció del tipus de fitxer i a l’exploració del fitxer carregat per detectar virus o altres amenaces de seguretat.
Així és com un verificador pot verificar la seguretat d’una aplicació respecte als seus punts d’accés.
# 6) Gestió de la sessió
Una sessió web és una seqüència de transaccions de sol·licitud i resposta HTTP enllaçades amb el mateix usuari. Les proves de gestió de sessions comproven com es gestiona la gestió de sessions a l'aplicació web.
Podeu provar la caducitat de la sessió després d'un temps d'inactivitat concret, la finalització de la sessió després de la vida màxima, la finalització de la sessió després de tancar la sessió, comprovar l'abast i la durada de les cookies de sessió, comprovar si un sol usuari pot tenir diverses sessions simultànies, etc.
# 7) Gestió d'errors
La prova de gestió d'errors inclou:
Comproveu si hi ha codis d'error : Per exemple, proveu el temps d'espera de la sol·licitud 408, 400 sol·licituds incorrectes, 404 no trobades, etc. Per provar-les, heu de fer determinades sol·licituds a la pàgina de manera que es retornin aquests codis d'error.
Els codis d'error es retornen amb un missatge detallat. Aquests missatges no haurien de contenir cap informació crítica que es pugui utilitzar amb finalitats de pirateria
Comproveu si hi ha rastres de pila : Inclou bàsicament algunes aportacions excepcionals a l'aplicació, de manera que el missatge d'error retornat contingui traces de pila que tinguin informació interessant per als hackers.
# 8) Funcionalitats de risc específiques
Principalment, les dues funcionalitats de risc són pagaments i càrregues de fitxers . Aquestes funcionalitats s’han de provar molt bé. Per a les càrregues de fitxers, heu de provar principalment que restringeixi la càrrega de fitxers no desitjats o malintencionats.
Per als pagaments, heu de provar principalment si hi ha vulnerabilitats d’injecció, emmagatzematge criptogràfic insegur, desbordaments de memòria intermèdia, endevinació de contrasenyes, etc.
=> Contacti amb nosaltres per suggerir un llistat aquí.Per llegir més:
- Proves de seguretat d'aplicacions web
- Top 30 de les preguntes de les entrevistes sobre proves de seguretat
- Diferència entre SAST / DAST / IAST / RASP
- SANS Top 20 Vulnerabilitats de seguretat
Lectura recomanada
- Guia de proves de seguretat d'aplicacions web
- Proves alfa i proves beta (guia completa)
- Tutorial de proves de magatzem de dades de proves ETL (una guia completa)
- Proves de seguretat de xarxa i millors eines de seguretat de xarxa
- Guia per a principiants sobre proves de penetració d'aplicacions web
- Guia completa de proves de verificació de compilació (proves BVT)
- Proves funcionals contra proves no funcionals
- Una guia completa de proves de penetració amb casos de prova de mostra