Topp 20 OWASP-sårbarheter och hur man åtgärdar dem Infografik
Open Web Application Security Project (OWASP) är en väletablerad organisation som ägnar sig åt att förbättra säkerheten för webbapplikationer genom att skapa verktyg, dokumentation och information - den senare inkluderar en årlig topp 10 av sårbarheter i webbapplikationer. Följande är en sammanställning av de senaste kritiska sårbarheterna som dyker upp på listorna, samt information om hur du åtgärdar var och en av dem.
De främsta OWASP-sårbarheterna
1. SQL Injektion
Beskrivning: Sårbarheter vid SQL-inmatning uppstår när data kommer in i ett program från en ej betrodd källa och används för att dynamiskt konstruera en SQL-fråga. SQL-inmatning kan leda till att data går förlorade eller skadas, att de inte är ansvariga eller att åtkomst nekas. Injektion kan ibland leda till fullständigt övertagande av värden.
Korrigering/rekommendation: Korrekt validering av indata på serversidan måste användas för att filtrera bort farliga tecken från användarindata. Dessutom kan användning av förberedda uttalanden/parametriserade lagrade procedurer säkerställa att indata bearbetas som text.
Exempel på kodavsnitt (validering av indata):
Strängindata=request.getParameter ("SeqNo");
Sträng characterPattern="[0-9a-zA-Z]";
if (! input. matches (characterPattern)){
out.println ("ogiltig inmatning ");
}
2. XSS-skript (Cross Site)
Beskrivning: I dessa fall bearbetas ogiltiga användarkontrollerade data i programmet, vilket leder till att skadliga skript körs. XSS-sårbarheter kan göra det möjligt för angripare att samla in användarinformation och/eller injicera HTML-kod i det sårbara webbprogrammet.
Korrigering/rekommendation: Korrekt validering av indata på serversidan och kodning av utdata bör användas på både klient- och serversidan för att förhindra körning av skript. Farliga tecken ska filtreras bort från användarindata [t.ex.: | , & , ; , $, % , @ , ' , " , \' , \" , <> ,() , + , CR (vagnretur, ASCII 0x0d) , LF (Radmatning, ASCII 0x0a),(kommatecken) ,\].
Exempel på kodavsnitt (kodningsteknik):
<input type="text" maxlength="30" name="ecsChangePwdForm" size="40" readonly="true" värde='<%=ESAPI.encoder() .encodeForHTML (request.getParameter ("användarnamn"))%>'/>
3. Informationsläckage
Beskrivning: Webbprogrammet kan avslöja systemdata eller felsökningsinformation genom att generera undantag eller generera felmeddelanden. Läckage av systemdata eller felsökning av information via en utdataström eller loggningsfunktion kan göra det möjligt för angripare att få kunskap om programmet och skapa specialiserade attacker mot det.
Fix/Rekommendation:
- Se till att felkoder och andra meddelanden som är synliga för slutanvändare inte innehåller känslig information.
- Rensa alla meddelanden och ta bort onödig känslig information.
- Se till att felsökning, felmeddelanden och undantag inte visas.
Exempel på kodavsnitt:
catch (Undantag e)
{
if(log.isDebugEnabled()) log.debug (kontext, EVENTS. ADHOC,
"Fångad ogiltigGSMException Exception -- "
+ e.toString() );
}
4. Injektion av ram
Beskrivning: Felaktig validering av indataparametrar kan leda till att angripare matar in ramar för att kompromettera konfidentiell användarinformation. Raminjektion är en vanlig metod som används i nätfiskeattacker
Korrigering/rekommendation: Använd en vitlista över acceptabla indata som strikt överensstämmer med säkra specifikationer
Exempel på kodavsnitt:
Sträng input=request.getParameter ("indata");
Strängteckenmönster="[./a-zA-Z0-9?"="&]";
if (! inmatning. matchar (teckenmönster)){
out.println ("ogiltig inmatning ");
}
5. Omdirigering av webbadresser
Beskrivning: Även om det är vanligt att webbprogram omdirigerar eller vidarebefordrar användare till andra webbplatser/sidor, utnyttjar angripare ofta sårbara program utan korrekt omdirigeringsvalidering på plats. Detta kan leda till skadlig omdirigering till en sida som inte är betrodd.
Åtgärd/rekommendation: Använd en vitlista över acceptabla indata som strikt överensstämmer med specifikationerna och för godkända webbadresser eller domäner som används för omdirigering.
Exempel på kodavsnitt:
Sträng input=request.getParameter ("indata");
Strängteckenmönster="[./a-zA-Z0-9?"="&]";
if (! inmatning. matchar (teckenmönster)){
out.println ("ogiltig inmatning ");
}
6. Timeout för missad session
Beskrivning: Angripare kan få obehörig åtkomst till webbprogram om tidsgränser för inaktivitet inte är korrekt konfigurerade.
Korrigering/rekommendation: Se till att timeout-funktionen är korrekt konfigurerad och fungerar.
Exempel på kodavsnitt:
<webapp>
<session-config>
<session-timeout>15</session-timeout>
</session-config>
</webapp>
7. Känslig information som skickas som klartext i GET URL
Beskrivning: Webbprogram som använder GET-begäranden för att skicka information via frågesträngen gör det i klartext. Detta gör att all känslig information som skickas med GET blir synlig i webbläsarhistoriken och serverloggarna.
Korrigering/rekommendation: Om du använder POST i stället för GET ser du till att konfidentiell information inte visas i frågesträngsparametrarna.
8. Sessions-ID-cookies är inte markerade som säkra
Beskrivning: Om sessions-ID-cookies för ett webbprogram markeras som säkra kommer webbläsaren inte att överföra dem via en okrypterad HTTP-begäran. Om du inte markerar dem som sådana kan cookies vara tillgängliga och synliga för angripare i klartext.
Åtgärd/rekommendation: Se till att känsliga cookies är inställda med attributet "säker" för att säkerställa att de alltid överförs via HTTPS.
Exempel på kodavsnitt:
Cookie cookie=ny cookie ("myCookieName");
cookie.secure(sant);
9. Skript över flera ramar (XFS)
Beskrivning: XFS-kryphål används tillsammans med XSS för att dirigera webbläsare till en webbsida som kontrolleras av angripare. I dessa fall läser den skadliga sidan in en sida från tredje part i en HTML-ram. Skript på angriparens sida kan sedan stjäla data från sidan från tredje part, utan att användaren vet om det.
>Korrigering/rekommendation: Korrekt validering bör användas för att filtrera bort eventuella skadliga indata som kan matas in i en ram och köras i användarens webbläsare, inom ramen för huvudsidans ram.
Exempel på kodavsnitt:
if (top == self) }
document.documentElement.style.display='block';
}
annars {
top.location=self.location;
}
10. Känslig information visas som klartext på skärmen
Beskrivning: Känslig information (t.ex. lösenord, kreditkortsinformation) bör inte visas som klartext på skärmen. Förutom axelsurfningsattacker hamnar känsliga data som lagras i klartext ofta i cacheminnen på klientsidan - som lätt kan stjälas om de upptäcks.
Åtgärd/rekommendation: Känslig information bör maskeras så att den inte är synlig för användarna
Exempel på kodavsnitt:
<asp:TextBox ID="txtSSN" TabIndex="6" runat="server" Width="206px" MaxLength="11" TextMode="Password"></asp:TextBox>
11. Känslig information cachad
Beskrivning: Webbläsare lagrar vanligtvis en kopia av begärda objekt i sina cacheminnen: webbsidor, bilder med mera. Detta skapar en säkerhetslucka för program som lagrar, bearbetar och visar känsliga data, eftersom angripare som får tillgång till användarens webbläsarcache har tillgång till all information som finns där.
Korrigering/rekommendation: HTTP Cache-Control-huvuden bör användas, till exempel Cache-Control: no-cache, no-store Pragma: no-cache.
Exempel på kodavsnitt:
<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />
<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Expires" content="0" />
12. Otillräcklig krypteringsstyrka
Beskrivning: Program som använder mindre än 1024 bitars nyckelstorlekar för kryptering kan utnyttjas via brute force-attacker.
Korrigering/rekommendation: Använd en högre bitnyckelstorlek för version, 2048 bitar eller större.
13. CRLF-insprutning (vagnretur och linjematning)
Beskrivning: CRLF-sårbarheter inträffar när skadligt innehåll infogas i webbläsarens HTTP-svarshuvuden efter att en intet ont anande användare klickar på en skadlig länk. Hackare injicerar vanligtvis skadlig kod i användarens webbläsare via webbapplikationen/servern, vilket gör det svårt att upptäcka den tillfälligt.
Åtgärd/rekommendation: URL-koda alla strängar före överföring. Se till att skalmetatecken och kommandoavgränsare (t.ex. ; CR eller LF) filtreras från användardata innan de överförs.
Exempel på kodavsnitt:
Sträng författare=request.getParameter(AUTHOR_PARAM);
Cookie cookie=ny cookie ("författare", ESAPI.encoder().encodeForURL (författare));
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);
14. Överträdelse av förtroendegränser
Beskrivning: Webbprogram blandar ofta felaktigt betrodda och ej betrodda data i samma datastrukturer, vilket leder till incidenter där ovaliderade/ofiltrerade data är betrodda/används.
Korrigering/rekommendation: Korrekt validering av indata och kodning av utdata bör användas för data innan de flyttas till betrodda gränser.
Exempel på kodavsnitt:
Sträng sessionPolicyId=request.getParameter("id");
if(sessionPolicyId.matches("[0-9a-zA-Z_]+") {
session.setAttribute("sessionPolicyId",sessionPolicyId);
}
15. Genomgång av kataloger
Beskrivning: Genom att acceptera användarindata som styr eller påverkar filsökvägar/namn som används i filsystemåtgärder kan sårbara webbprogram göra det möjligt för angripare att komma åt eller ändra annars skyddade systemresurser.
Korrigering/rekommendation: En vitlista över acceptabla datainmatningar som strikt överensstämmer med specifikationerna kan förhindra kryphål i katalogbläddringar.
Exempel på kodavsnitt:
Sträng inmatning=request.getParameter("fileName");
if (ESAPI.validator().isValidFileName(String context, String input, boolean allowNull)){
File file=new File(input);
}
16. Fixering av sessioner
Beskrivning: I dessa fall autentiserar sårbara webbprogram användare utan att först förstöra befintliga sessioner som är associerade med dessa användare. Detta gör det möjligt för angripare att komma åt användarnas konton genom att kapa deras aktiva sessioner.
Åtgärd/rekommendation: Förstör alla befintliga sessionsidentifierare innan du auktoriserar en ny användarsession.
Exempel på kodavsnitt:
session.invalidate();
session=request.getSession(sant);
17. Användning av en riskfylld kryptografisk algoritm
Beskrivning: Webbapplikationer som använder icke-standardiserade algoritmer är svagt krypterade, vilket gör att hackare kan få åtkomst relativt enkelt med hjälp av brute force-metoder.
Korrigering/rekommendation: När du lagrar eller överför känsliga data bör du använda starka, uppdaterade kryptografiska algoritmer för att kryptera dessa data innan du skickar/lagrar.
Exempel på kodavsnitt:
MessageDigest md=MessageDigest.getInstance("SHA-256");
FileInputStream fis=new FileInputStream("c:\\loging.log");
byte [] dataBytes=ny byte [1024];
int nread=0;
medan ((nread=fis.read(dataBytes)) != -1) {
md.update(dataBytes, 0, nread);
};
byte [] mdbytes=md.digest();
18. Hantering av autentiseringsuppgifter
Beskrivning: Att lagra lösenord i klartext kan lätt leda till systemkompromisser - särskilt om det gäller konfigurations-/källfiler.
Åtgärd/rekommendation: Undvik att lagra lösenord på lättillgängliga platser. Använd kryptografiska hashvärden som ett alternativ till oformaterad text.
19. SQL Injektion Viloläge
Beskrivning: Hibernate är ett populärt ORM-ramverk för Java - som sådant tillhandahåller det flera metoder som gör det möjligt att köra inbyggda SQL-frågor. Angripare utnyttjar ofta Hibernate för att köra skadliga, dynamiskt skapade SQL-satser.
Korrigering/rekommendation: Korrekt validering av indata på serversidan kan fungera som ett grundläggande skydd för att filtrera bort farliga tecken. Förberedda instruktioner/parametriserade lagrade procedurer kan användas för att återge data som text före bearbetning eller lagring.
Exempel på kodavsnitt:
Fråga hqlQuery=session.createQuery ("välj produkt från beställningar som order där orders.id =?");
Lista resultat=hqlQuery.setString(0, "123-ADB-567-QTWYTFDL").list();
20. Felaktig avstängning eller frisläppning av resurser
Beskrivning: Felaktig resursavstängning inträffar när ett webbprogram inte kan frigöra en systemresurs innan den görs tillgänglig för återanvändning. En överbelastningsattack (Dos) kan sedan startas genom att tömma serverns resurspool.
Korrigering/rekommendation: Alla skapade eller allokerade resurser måste frisläppas korrekt efter användning.
Exempel på kodavsnitt:
prova {
Connection con=DriverManager.getConnection(some_connection_string);
}
catch ( Undantag e ) {
log( e );
}
slutligen {
if( stmt != null )
stmt.close();
con.close() }
Kort sagt är de 20 objekten som anges ovan de vanligaste sårbarheterna i webbapplikationer, enligt OWASP. Även om många av dessa kan åtgärdas genom säkrare kodningsmetoder, kan vissa kräva identifiering av relevanta leverantörsspecifika korrigeringar. Detta beror i slutändan på vilka specifika tekniker, ramverk och paket som används i din webbapplikation.
Behöver du ett enklare sätt att upptäcka sårbarheter i din webbapplikation? Drivs av policydriven testning kan UpGuard automatiskt skanna och övervaka din webbapplikation för felkonfigurationer och säkerhetsluckor.
Infografik
