Det är inte bara ett block med handfulla tecken som du behöver för att svartlista. I säkerhet går vi efter detta dogm:

"Det finns saker vi vet som vi vet. Det finns kända okända. Det vill säga det finns saker som vi nu vet att vi inte vet. Men det finns också okända okända. Det finns saker som vi inte vet vi inte vet. "

Svartlista kan hjälpa dig att förhindra de två första fallen, en vitlista hjälper till att täcka alla tre :)

Även om det är lätt att identifiera och validera en uppsättning tecken som är ofarliga, är det svårt att identifiera alla kända dåliga. De flesta antivirusprogram använder blacklist-tillvägagångssätt (signaturer), men de misslyckas fortfarande med att fånga en 0-dagars eftersom det var något de inte visste som känt dåligt och därför inte hade någon signatur för det.

Varför är whitelist-tillvägagångssätt också bättre än blacklist-tillvägagångssätt som nämnts av OWASP. Varför inte bara blockera en handfull tecken som används i XSS som <,>, etc

Svartlistor är statiska i den meningen, de förhindrar att "känt dåligt" händer. Problemet med detta är att det finns nya attackvektorer som hittas varje dag och du måste ständigt uppdatera din svarta lista för att vara säker. Vitlista är å andra sidan mer robust eftersom du kan skapa ett filter på exakt vad du vill ha. Det svarar på din fråga om varför vitlistor föreslås av OWASP.

Jag tror att du kanske har avvisat ESAPI för snabbt. För att försvara dig mot XSS, rekommenderar jag att du släpper utdata: var som helst där du infogar data dynamiskt i ett HTML-dokument, undgår data (på ett sätt som är lämpligt för det analysera sammanhanget). ESAPI tillhandahåller bibliotek för att fly och är mycket användbart. Detta innebär inte att "ändra din inmatning".

För mer, läs OWASP: s XSS (Cross Site Scripting) Prevention Cheat Sheet och Kan någon förklara XSS för en idiot ? och Filtrera användarinmatning före databasen eller på visning?, och Canonicalization & Output Encoding.

gör ingångsfiltrering

Nej, nej, nej.

Mata in alla fall validering - acceptera eller avvisa inmatningen baserat på regler. Försök inte ändra ingångsdata. Om gränssnittet mellan din webbserver och ditt applikationsspråk tillåter innehåll genom vilket komprometterar ditt applikationsspråk så är det något väldigt, väldigt fel. Visst kan du inte hantera den här typen av scenario i din applikationskod.

Sårbarheter i applikationer uppstår vanligtvis vid den punkt där data lämnar ditt applikationsspråk - och i fallet med XSS är det här de alltid uppstår. Så det här är den punkt där du bör tillämpa någon omvandling till data. En omvandling måste vara lämplig för vart data går - hur du släpper ut data du skriver till en databas skiljer sig mycket från data som ska skrivas in i html.

Helst bör följande steg utföras vid inmatning:

1. Filter (valfritt). Ta bort mellanslag runt värden. Eller till exempel för ett telefonnummer kanske du vill ta bort mellanslag, bindestreck och perioder, eftersom vissa försöker skriva in saker som 046 339 1312 .

2. Validera .

   a. Detta förhindrar användarfel som filtret inte tar upp.

   b. Valideringskontroller ska fungera som vitlista. Med korrekt flykt (se punkt 3 nedan) borde detta inte behövas för säkerhet, men det kan blockera en oupptäckt attack i framtiden. Var dock försiktig, det är ofta svårare än det verkar.

   Oavsett om du ska gå efter något grundläggande (som bara söka efter ett @ -tecken när du validerar e-postadresser) eller en exakt och strikt regelbundet uttryck beror på om du känner till alla möjliga värden och om du verkligen behöver få det rätt. För en webbplats med kreditkortsuppgifter i sin databas kanske du vill spendera lite mer tid på att undersöka möjliga ingångar.

   c. Du kanske också vill validera det, existerar domänen i den här e-postadressen ens? Eller är detta nummer verkligen giltigt? Du kan till och med försöka om en mailserver accepterar användaren (Gmail kommer att fel när en användare inte finns, även innan du verkligen skickade något), men servern kan vara nere. SMTP skulle hantera detta åt dig och försena leveransen, men din live e-postadresskontroll kommer att berätta för användaren att hans adress inte finns medan den helt gör det.

3. Fly . Detta bör göras både för in- och utdata . Mata in när du sparar den i en databas, mata ut när du visar den. Ja, undvik också data som kommer direkt från din databas. En apostrof kan vara helt ofarlig i HTML, medan användning i Javascript kan ge en fantastisk XSS-möjlighet. Eller en < kommer inte att undvikas av mysql_real_escape_string , men om du sedan skickar den till en HTML-sida har du fått en annan XSS.

ol >

Jag kan inte tänka mig något användningsfall där stegen ovan skulle göra en svartlista praktisk eller nödvändig, så jag skulle rekommendera att inte använda den. Det kan dock alltid finnas en anledning. Att fly så ska ta hand om resten oavsett, men det är bra att ha ett nytt försvar.

När det är tillräckligt viktigt kan du också skriva ett enhetstest för att testa alla möjliga ingångar och vanliga utnyttjanden: .. /, ', ", \, siffror, strängar eller till och med hela ASCII-uppsättningen.