Top 20 OWASP-sårbarheder, og hvordan man løser dem infografik
Open Web Application Security Project (OWASP) er en veletableret organisation, der er dedikeret til at forbedre webapplikationssikkerheden gennem oprettelse af værktøjer, dokumentation og information - sidstnævnte inkluderer en årlig top 10 over webapplikationssårbarheder. Det følgende er en samling af de seneste kritiske sårbarheder, der dukker op på dens lister, samt oplysninger om, hvordan man afhjælper hver af dem.
De mest sårbare sårbarheder i OWASP
1. SQL Injektion
Beskrivelse: Sårbarheder i forbindelse med SQL-injektion opstår, når data kommer ind i et program fra en kilde, der ikke er tillid til, og bruges til dynamisk at oprette en SQL-forespørgsel. SQL-injektion kan resultere i tab eller korruption af data, manglende ansvarlighed eller nægtelse af adgang. Injektion kan nogle gange føre til fuldstændig værtsovertagelse.
Rettelse/anbefaling: Korrekt inputvalidering på serversiden skal bruges til at filtrere farlige tegn fra brugerinput. Derudover kan brug af forberedte udsagn/parametriserede lagrede procedurer sikre, at input behandles som tekst.
Eksempel på kodestykke (inputvalidering):
Strenginput=request.getParameter ("SeqNo");
Streng characterPattern="[0-9a-zA-Z]";
Hvis (! input. matcher (characterPattern))
{
out.println ("Ugyldigt input ");
}
2. Cross Site (XSS) scripting
Beskrivelse: I disse tilfælde behandles ugyldige brugerstyrede data i programmet, hvilket fører til kørsel af skadelige instrukser. XSS-sårbarheder kan gøre det muligt for angribere at indsamle brugeroplysninger og/eller indsætte HTML-kode i det sårbare webprogram.
Rettelse/anbefaling: Korrekt inputvalidering og outputkodning på serversiden bør anvendes på både klient- og serversiden for at forhindre udførelse af scripts. Farlige tegn skal filtreres fra brugerinput [f.eks.: | , & , ; , $, % , @ , ' , " , \' , \" , <> ,() , + , CR (Carriage return, ASCII 0x0d) , LF (Line feed, ASCII 0x0a),(kommategn) ,\].
Eksempel på kodestykke (kodningsteknik):
<input type="text" maxlength="30" name="ecsChangePwdForm" size="40" readonly="true" value='<%=ESAPI.encoder().encodeForHTML(request.getParameter("userName"))%>'/>
3. Lækage af oplysninger
Beskrivelse: Webprogrammet kan afsløre systemdata eller fejlfindingsoplysninger ved at oprette undtagelser eller fejlmeddelelser. Lækage af systemdata eller fejlretning af information gennem en outputstrøm eller logningsfunktion kan give angribere mulighed for at få viden om applikationen og lave specialiserede angreb på den.
Rettelse/anbefaling:
- Sørg for, at fejlkoder og andre meddelelser, der er synlige for slutbrugere, ikke indeholder følsomme oplysninger.
- Rens alle meddelelser, fjern alle unødvendige følsomme oplysninger.
- Sørg for, at fejlfinding, fejlmeddelelser og undtagelser ikke er synlige.
Eksempel på kodestykke:
catch (Undtagelse e)
{
if(log.isDebugEnabled()) log.debug (kontekst, HÆNDELSER. ADHOC,
"Fanget ugyldig GSMException-undtagelse -- "
+ e.toString() );
}
4. Ramme indsprøjtning
Beskrivelse: Forkert validering af indtastningsparametre kan medføre, at angribere indsprøjter rammer for at kompromittere fortrolige brugeroplysninger. Rammeinjektion er en almindelig metode, der anvendes i phishing-angreb
Rettelse/anbefaling: Brug en hvidliste over acceptable input, der nøje overholder sikre specifikationer
Eksempel på kodestykke:
Strengindgang=request.getParameter ("input");
Strengtegnmønster="[./a-zA-Z0-9?"="&]";
Hvis (! input. matcher (tegnmønster))
{
out.println ("Ugyldigt input ");
}
5. URL-omdirigering
Beskrivelse: Selvom det er almindeligt, at webprogrammer omdirigerer eller videresender brugere til andre websteder/sider, udnytter hackere ofte sårbare programmer uden korrekt omdirigeringsvalidering. Dette kan føre til ondsindet omdirigering til en side, der ikke er tillid til.
Rettelse/anbefaling: Brug en hvidliste over acceptable input, der nøje overholder specifikationerne og for godkendte webadresser eller domæner, der bruges til omdirigering.
Eksempel på kodestykke:
Strengindgang=request.getParameter ("input");
Strengtegnmønster="[./a-zA-Z0-9?"="&]";
Hvis (! input. matcher (tegnmønster))
{
out.println ("Ugyldigt input ");
}
6. Manglende session timeout
Beskrivelse: Angribere kan få uautoriseret adgang til webprogrammer, hvis timeout for inaktivitet ikke er konfigureret korrekt.
Rettelse/anbefaling: Sørg for, at timeout-funktionaliteten er korrekt konfigureret og fungerer.
Eksempel på kodestykke:
<webapp>
<session-config>
<session-timeout>15</session-timeout>
</session-config>
</webapp>
7. Følsomme oplysninger, der sendes som klar tekst i GET-webadressen
Beskrivelse: Webprogrammer, der bruger GET-anmodninger til at overføre oplysninger via forespørgselsstrengen, gør det i klartekst. Dette gør alle følsomme oplysninger, der sendes med GET, synlige i browserhistorik og serverlogfiler.
Rettelse/anbefaling: Brug af POST i stedet for GET sikrer, at fortrolige oplysninger ikke er synlige i forespørgselsstrengparametrene.
8. Sessions-id-cookies, der ikke er markeret som sikre
Beskrivelse: Hvis sessions-id-cookies til et webprogram er markeret som sikre, sender browseren dem ikke via en ukrypteret HTTP-anmodning. Hvis du ikke markerer dem som sådan, kan cookies være tilgængelige og synlige for angribere i klartekst.
Rettelse/anbefaling: Sørg for, at følsomme cookies er indstillet med attributten "sikker" for at sikre, at de altid overføres via HTTPS.
Eksempel på kodestykke:
Cookie-cookie=ny cookie ("myCookieName");
cookie.secure(sand);
9. Cross Frame Scripting (XFS)
Beskrivelse: XFS-udnyttelser bruges sammen med XSS til at dirigere browsere til en webside, der kontrolleres af hackere. I disse tilfælde indlæser den skadelige side en tredjepartsside i en HTML-ramme. Scripts på angriberens side er derefter i stand til at stjæle data fra tredjepartssiden, uden at brugeren ved det.
>Rettelse/anbefaling: Korrekt validering bør bruges til at filtrere ethvert ondsindet input fra, der kan injiceres i en ramme og udføres i brugerens browser inden for rammerne af hovedsiderammen.
Eksempel på kodestykke:
if (top == self) }
document.documentElement.style.display='blok';
}
else {
top.location=self.location;
}
10. Følsomme oplysninger vises som klar tekst på skærmen
Beskrivelse: Følsomme oplysninger (f.eks. adgangskoder, kreditkortoplysninger) bør ikke vises som klar tekst på skærmen. Ud over skuldersurfing-angreb finder følsomme data, der er gemt som klar tekst, ofte væk i caches på klientsiden - som nemt kan stjæles, hvis de opdages.
Rettelse/anbefaling: Følsomme oplysninger skal maskeres, så de ikke er synlige for brugerne
Eksempel på kodestykke:
<asp:TextBox ID="txtSSN" TabIndex="6" runat="server" Width="206px" MaxLength="11" TextMode="Password"></asp:TextBox>
11. Følsomme oplysninger cachelagret
Beskrivelse: Browsere gemmer typisk en kopi af de ønskede emner i deres buffere: websider, billeder m.m. Dette skaber et sikkerhedshul for applikationer, der gemmer, behandler og viser følsomme data, da angribere, der får adgang til brugerens browsercache, har adgang til alle oplysninger indeholdt deri.
Rettelse/anbefaling: HTTP Cache-Control-headere bør bruges, såsom Cache-Control: no-cache, no-store Pragma: no-cache.
Eksempel på kodestykke:
<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />
<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Udløber" content="0" />
12. Utilstrækkelig krypteringsstyrke
Beskrivelse: Programmer, der bruger mindre end 1024 bit nøglestørrelser til kryptering, kan udnyttes via brute force-angreb.
Rettelse/anbefaling: Brug en højere version af bitnøglestørrelsen, 2048 bit eller større.
13. CRLF (vognretur og linjetilførsel) injektion
Beskrivelse: CRLF-udnyttelser opstår, når skadeligt indhold indsættes i browserens HTTP-svarheadere, efter at en intetanende bruger har klikket på et skadeligt link. Hackere vil typisk injicere ondsindet kode i brugerens browser via webapplikationen/serveren, hvilket gør det vanskeligt at opdage tilfældigt.
Rettelse/anbefaling: URL-kode alle strenge før transmission. Sørg for, at shell-metategn og kommandoterminatorer (f.eks. ; CR eller LF) filtreres fra brugerdata, før de overføres.
Eksempel på kodestykke:
Strengforfatter=request.getParameter(AUTHOR_PARAM);
Cookie-cookie=ny cookie("forfatter", ESAPI.encoder().encodeForURL(author));
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);
14. Overtrædelse af tillidsgrænser
Beskrivelse: Webprogrammer blander ofte fejlagtigt pålidelige og ikke-pålidelige data i de samme datastrukturer, hvilket fører til hændelser, hvor der er tillid til/brug for ikke-validerede/ufiltrerede data.
Rettelse/anbefaling: Korrekt inputvalidering og outputkodning bør bruges på data, før de flyttes til pålidelige grænser.
Eksempel på kodestykke:
Streng sessionPolicyId=request.getParameter("id");
if(sessionPolicyId.matches("[0-9a-zA-Z_]+") {
session.setAttribute("sessionPolicyId",sessionPolicyId);
}
15. Gennemgang af vejvisere
Beskrivelse: Ved at acceptere brugerinput, der styrer eller påvirker filstier/navne, der bruges i filsystemhandlinger, kan sårbare webprogrammer gøre det muligt for hackere at få adgang til eller ændre ellers beskyttede systemressourcer.
Rettelse/anbefaling: En hvidliste over acceptable datainput, der nøje overholder specifikationerne, kan forhindre udnyttelse af kataloggennemgang.
Eksempel på kodestykke:
Strenginput=request.getParameter("fileName");
if (ESAPI.validator().isValidFileName(Strengkontekst, Strenginput, boolesk allowNull)){
Filfil=ny fil(input);
}
16. Session fiksering
Beskrivelse: I disse tilfælde godkender sårbare webprogrammer brugere uden først at ødelægge eksisterende sessioner, der er knyttet til de pågældende brugere. Dette giver angribere mulighed for at få adgang til brugernes konti ved at kapre deres aktive sessioner.
Rettelse/anbefaling: Ødelæg alle eksisterende sessions-id'er, før du godkender en ny brugersession.
Eksempel på kodestykke:
session.invalidate();
session=request.getSession(sand);
17. Brug af en risikabel kryptografisk algoritme
Beskrivelse: Webprogrammer, der bruger ikke-standardiserede algoritmer, er svagt krypterede, hvilket gør det relativt nemt for hackere at få adgang ved hjælp af brute force-metoder.
Rettelse/anbefaling: Når du gemmer eller overfører følsomme data, skal du bruge stærke, opdaterede kryptografiske algoritmer til at kryptere disse data, før du sender/gemmer.
Eksempel på kodestykke:
MessageDigest md=MessageDigest.getInstance("SHA-256");
FileInputStream fis=ny FileInputStream("c:\\loging.log");
byte[] dataBytes=ny byte[1024];
int nread=0;
mens ((nread=fis.read(dataBytes)) != -1) {
md.update(dataBytes, 0, nread);
};
byte[] mdbytes=md.digest();
18. Forvaltning af legitimationsoplysninger
Beskrivelse: Lagring af adgangskoder i almindelig tekst kan nemt medføre kompromittering af systemet - især hvis der er tale om konfigurations-/kildearkiver.
Rettelse/anbefaling: Undgå at gemme adgangskoder på let tilgængelige steder. Brug kryptografiske hashes som et alternativ til almindelig tekst.
19. SQL Injektion dvale
Beskrivelse: Dvaletilstand er en populær ORM-struktur til Java - den indeholder derfor flere metoder, der gør det muligt at udføre oprindelige SQL-forespørgsler. Angribere udnytter ofte dvaletilstand til at udføre ondsindede, dynamisk oprettede SQL-sætninger.
Rettelse/anbefaling: Korrekt inputvalidering på serversiden kan tjene som et grundlæggende forsvar for at filtrere farlige tegn fra. Forberedte sætninger/parametriserede lagrede procedurer kan bruges til at gengive data som tekst før behandling eller lagring.
Eksempel på kodestykke:
Query hqlQuery=session.createQuery("vælg produkt fra Ordrer som ordrer, hvor orders.id =?");
Listeresultater=hqlQuery.setString(0, "123-ADB-567-QTWYTFDL").list();
20. Forkert nedlukning eller frigivelse af ressourcer
Beskrivelse: Forkert lukning af ressourcer opstår, når et webprogram ikke frigiver en systemressource, før den gøres tilgængelig til genbrug. Et denial of service-angreb (Dos) kan derefter startes ved at opbruge serverens ressourcepulje.
Rettelse/anbefaling: Alle oprettede eller tildelte ressourcer skal frigives korrekt efter brug.
Eksempel på kodestykke:
prøv {
Connection con=DriverManager.getConnection(some_connection_string);
}
fangst ( Undtagelse e ) {
log( e );
}
endelig {
if( stmt != null )
stmt.close();
con.close() }
Kort sagt er de 20 punkter, der er anført ovenfor, de mest almindeligt forekommende sårbarheder i webapplikationer pr. OWASP. Mens mange af disse kan afhjælpes gennem sikrere kodningspraksis, kan nogle kræve identifikation af relevante leverandørspecifikke patches. Dette afhænger i sidste ende af, hvilke specifikke teknologier, rammer og pakker, der bruges i din webapplikation.
Har du brug for en nemmere måde at opdage sårbarheder i din webapplikation på? UpGuard er drevet af politikdrevet test og kan automatisk scanne og overvåge din webapplikation for fejlkonfigurationer og sikkerhedshuller.
Infografik
