Owl for IIS

Owl for IIS identifiserer SQLs like før de blir henrettet i runtime. Det er ved å implementere Runtime Application Self-beskyttelse (RASP) modulen.

webapplikasjon blir inngang via spørre og legg parametere. Inngangen kan produsere cross-site scripting, SQL-injeksjon og andre sikkerhetsbrudd. Nå vet vi WAF har begrensninger som det ikke kjøres i prosessen, men i nettverket: 1. Noen kan være avhengig av SSL-tastene når trafikken er kryptert. De kan ikke håndtere DH saken 2. Det kan ikke være sikker på hvilken bruker som er ansvarlig for hvilke SQL-setninger som prosessen kan bruke en annen bruker til å kjøre SQLs 3. Sofistikert URL tukling kan lure WAF 4. Developer sette en bakdør i programmet (aktiveres av ekstra søkeparameter for å endelig kjøre dedikerte ondsinnet kode). Hvordan WAF kan finne det ut?

Ta følgende eksempel: bruker nettleseren sender denne HTTP-forespørsel for å få en liste over brukere i avdelingen http: //applicationHost/getData.aspx kode = derpatment. Men brukeren kan også endre manuelt til en annen kodeverdien som http: //applicationHost/getData.aspx kode = selskap. I tillegg til det kan si at SQLs blir utført av en tråd basseng som autentisert ved hjelp av noen generiske bruker. 1. Database verktøyet kan ikke fortelle hvem som oppsto forespørselen. 2. WAF trenger å være sofistikert for å finne ut noe er galt med nettadressen.

Det eneste alternativet du har å korrelere brukerdetaljer (navn og IP) med nøyaktige SQL-setning som applikasjonen utfører er ved å være på det punktet der søknaden sender SQL-setningen ut av prosessen. Det vil si at den virkelige SQL etter påføringen fullfører inngangen prosesserings. Ingen heuristikk, ingen falske positive. Owl for IIS tar sikte på å avdekke alle SQL-setninger

Hva er nytt i denne utgaven.

Versjon 1.3:

• oppdragsarkivet nå inkludere brukernavnet
• integrasjon med IBM Guardium å passere søknad brukernavn