Owl för IIS identifierar SQL-satser precis innan de genomförs i runtime. Det är genom att genomföra Runtime Application självförsvar (RASP) modul.
Din webbapplikation blir ingång via fråge och postparametrar. Ingången kan producera cross-site scripting, SQL-injektion och andra säkerhetsöverträdelser. Vid det här laget vet vi WAF har begränsningar eftersom det inte körs i processen, men i nätverket: 1. Vissa kan vara beroende av SSL tangenterna när trafiken är krypterad. De kan inte hantera DH fallet 2. Det kan inte vara säker på vilken användaren är ansvarig för vilka SQL-satser som processen kan använda en annan användare att köra SQL-satser 3. Sofistikerad URL manipulation kan lura WAF 4. Developer sätta en bakdörr i ansökan (aktiveras av extra frågeparameter för att slutligen köra dedikerad skadlig kod). Hur WAF kan räkna ut?
Ta följande exempel: användar webbläsare skickar denna HTTP-förfrågan för att få en lista över användare i http avdelningen: //applicationHost/getData.aspx kod = derpatment. Men användaren kan också manuellt ändra till en annan kod värde som http: kod = företag //applicationHost/getData.aspx?. I tillägg till detta kan säga att de SQL-satser som exekveras av en tråd pool som autentiseras med några allmänna användare. 1. databasverktyg kan inte säga vem gav upphov till begäran. 2. WAF måste vara sofistikerad för att räkna ut något är fel med webbadressen.
Det enda alternativet du måste korrelera användaruppgifter (namn och IP) med exakt SQL-sats som programmet utför är genom att vara vid den punkt där ansökan skickar SQL-satsen ur processen. Det är den verkliga SQL efter ansökan slutföra ingångs bearbetning. Inga heuristik, ingen falsk positiv. Owl för IIS siktar på att exponera alla SQL-satser
Vad är nytt i den här versionen.
Version 1.3:
- revision filen nu inkluderar användarnamn
- integration med IBM Guardium att passera ansökan användarnamn
Kommentarer hittades inte