Webapplikasjonsutviklere stoler ofte på at de fleste brukere skal følge reglene og bruke et program som det er ment å bli brukt, men hva med når brukeren (eller en hacker) bøyer reglene? Hva om en bruker hopper over det fancy webgrensesnittet og begynner å rote rundt under hetten uten de begrensningene som nettleseren pålegger?
Hva om Firefox?
Firefox er den valgte nettleseren for de fleste hackere på grunn av sin plug-in-vennlig design. Et av de mest populære hackerverktøyene for Firefox er et tillegg som heter Tamper Data. Tamper Data er ikke et superkomplisert verktøy, det er bare en proxy som setter seg inn mellom brukeren og nettsiden eller webapplikasjonen som de surfer på.
Tamper Data lar en hacker å skrille tilbake gardinen for å se og rote med alle HTTP-magiene som finner sted bak kulissene. Alle de GET og POST-ene kan manipuleres uten de begrensninger som brukergrensesnittet angir i nettleseren.
Hva er å like?
Så hvorfor virker hackere som Tamper Data så mye, og hvorfor skal webapplikasjonsutviklere bryr seg om det? Hovedårsaken er at det tillater en person å tukle med dataene som sendes frem og tilbake mellom klienten og serveren (derav navnet Tamper Data). Når Tamper Data er startet og en webapp eller et nettsted lanseres i Firefox, vil Tamper Data vise alle feltene som tillater brukerinngang eller manipulering. En hacker kan da bytte et felt til en "alternativ verdi" og sende dataene til serveren for å se hvordan den reagerer.
Hvorfor dette kan være farlig for et program
Si at en hacker besøker et online shoppingområde og legger til et element i sin virtuelle handlekurv. Webapplikasjonsutvikleren som bygde handlekurven, kan ha kodet vognen for å godta en verdi fra brukeren, for eksempel Mengde = "1" og begrenset brukergrensesnittelementet til en rullegardinboks med forhåndsbestemte valg for mengden.
En hacker kan forsøke å bruke Tamper Data for å omgå begrensningene i rullegardinlisten som bare tillater brukere å velge fra et sett med verdier som 1, 2, 3, 4 og 5. Ved hjelp av Tamper Data kan hackeren prøve å angi en annen verdi av si "-1" eller kanskje ".000001".
Hvis utvikleren ikke har korrekt kodet sin inntaksvalideringsrutine, kan denne verdien "-1" eller ".000001" muligens ende opp med å bli sendt til formelen som brukes til å beregne kostnaden for elementet (for eksempel pris x mengde). Dette kan føre til uventede resultater, avhengig av hvor mye feilkontroll som skjer, og hvor stor tillit utvikleren har i dataene som kommer fra klientsiden. Hvis handlekurven er dårlig kodet, kan hackeren ende opp med å få en mulig utilsiktet stor rabatt, en tilbakebetaling på et produkt de ikke engang kjøpte, en butikk kreditt, eller hvem vet hva annet.
Mulighetene for misbruk av et webprogram ved hjelp av Tamper Data er uendelige. Hvis jeg var en programvareutvikler, ville det bare holde meg om natten å bare vite at det finnes verktøy som Tamper Data der ute.
På flippsiden er Tamper Data et utmerket verktøy for sikkerhetsbevisste applikasjonsutviklere å bruke, slik at de kan se hvordan deres applikasjoner svarer på klientsidenes datahåndteringsangrep.
Utviklere lager ofte "Bruk Cases" for å fokusere på hvordan en bruker vil bruke programvaren til å oppnå et mål. Dessverre ignorerer de ofte den dårlige fyrfaktoren. App-utviklere må sette på seg de slemme hatterne og lage "Misuse Cases" for å regne for hackere som bruker verktøy som Tamper Data.
Tamper Data bør være en del av deres sikkerhetstestars arsenal for å sikre at innsats på klientsiden er validert og verifisert før det kan påvirke transaksjoner og server-side prosesser. Hvis utviklere ikke tar en aktiv rolle i å bruke verktøy som Tamper Data for å se hvordan deres applikasjoner svarer på angrep, vil de ikke vite hva de kan forvente og kan ende opp med å betale regningen for 60 "Plasma TV som hackeren nettopp har kjøpt for 99 cent ved hjelp av deres defekte handlekurv.
