Owl til IIS identificerer SQLs lige før de bliver henrettet i runtime. Det er ved at gennemføre Runtime Application Self-Protection (RASP) modul.
Din web-applikation bliver input via forespørgsler og post parametre. Indgangen kan producere cross-site scripting, SQL injektion og andre brud på sikkerheden. Nu ved vi, WAF har begrænsninger, da det ikke kører i processen, men i netværket: 1. Nogle kan være afhængig af SSL taster, når trafikken er krypteret. De kan ikke håndtere DH sagen 2. Det kan ikke være sikker på, hvilken bruger er ansvarlig for hvilke SQL-sætninger, som processen kan anvende en anden bruger til at køre SQLs 3. Sofistikeret URL manipulation kan narre WAF 4. Udvikler sætte en bagdør i ansøgningen (aktiveres ved ekstra søgeparameter for endelig at køre dedikeret skadelig kode). Hvordan WAF kan regne det ud?
Tag følgende eksempel: bruger browser sender denne HTTP-anmodning for at få en liste over brugere i afdelingen http:? //applicationHost/getData.aspx Kode = derpatment. Men brugeren kan også ændre manuelt i en anden kode værdi ligesom http:? //applicationHost/getData.aspx Kode = selskab. Hertil kommer, at lad os sige, at SQLs bliver udført af en tråd pulje, godkendt ved hjælp af nogle generiske bruger. 1. Database værktøj kan ikke fortælle, hvem stammer anmodningen. 2. WAF skal være sofistikeret at finde ud af noget er galt med URL.
Den eneste mulighed, du er nødt til at korrelere brugernes oplysninger (navn og IP) med nøjagtig SQL-sætning, at ansøgningen udfører, er ved at være på det punkt, hvor ansøgningen sender SQL-sætningen ud af processen. Det er den egentlige SQL efter påføringen fuldføre input forarbejdning. Ingen heuristik, ingen falsk positive. Ugle til IIS sigter på at afsløre alle SQL-sætninger
Hvad er nyt i denne udgivelse:.
Version 1.3:
- revisionsfil nu omfatter brugernavn
- integration med IBM Guardium at passere ansøgning brugernavn
Kommentarer ikke fundet