Webapplikationsudviklere stoler ofte på, at de fleste brugere skal følge reglerne og bruge en applikation som den er beregnet til at blive brugt, men hvad med når brugeren (eller en hacker) bøjer reglerne? Hvad hvis en bruger hopper over den fancy webgrænseflade og begynder at rive rundt under emhætten uden de begrænsninger, der pålægges af browseren?
Hvad med Firefox?
Firefox er den valgte browser til de fleste hackere på grund af dens plug-in venlige design. Et af de mere populære hackerværktøjer til Firefox er en tilføjelse, der hedder Tamper Data. Tamper Data er ikke et superkompliceret værktøj, det er blot en proxy, der indsætter sig selv imellem brugeren og websitet eller webapplikationen, som de browser.
Tamper Data tillader en hacker at skrække gardinen for at se og røre med alle de HTTP "magiske" der finder sted bag kulisserne. Alle de GET'er og POST'er kan manipuleres uden de begrænsninger, der pålægges af brugergrænsefladen, der ses i browseren.
Hvad er der at lide?
Så hvorfor kan hackere lide Tamper Data så meget, og hvorfor skal webapplikationsudviklere bryde sig om det? Hovedårsagen er, at det tillader en person at manipulere med de data, der sendes frem og tilbage mellem klienten og serveren (dermed navnet Tamper Data). Når Tamper Data startes, og en webapp eller hjemmeside startes i Firefox, viser Tamper Data alle de felter, der tillader brugerindlæsning eller manipulation. En hacker kan derefter ændre et felt til en "alternativ værdi" og sende dataene til serveren for at se, hvordan det reagerer.
Hvorfor dette kunne være farligt for et program
Sig en hacker besøger et online shopping site og tilføjer et element til deres virtuelle indkøbskurv. Den webapplikationsudvikler, der byggede indkøbskurven, kan have kodet vognen for at acceptere en værdi fra brugeren som f.eks Mængde = "1" og begrænsede brugergrænsefladeelementet til en drop-down boks med forudbestemte valg for mængden.
En hacker kunne forsøge at bruge Tamper Data for at omgå begrænsningerne i rullemenuen, som kun tillader brugere at vælge fra et sæt værdier som 1, 2, 3, 4 og 5. Ved hjælp af Tamper Data kunne hacker forsøge at indtaste en anden værdi af sige "-1" eller måske ".000001".
Hvis udvikleren ikke korrekt har kodet deres input valideringsrutine, kan denne værdi "-1" eller ".000001" muligvis ende med at blive overført til den formel, der bruges til at beregne prisen på elementet (fx Price x Quantity). Dette kan medføre nogle uventede resultater afhængigt af, hvor meget fejlkontrol der foregår, og hvor stor tillid udvikleren har i dataene fra klientsiden. Hvis indkøbskurven er dårligt kodet, kan hackeren ende med at få en mulig utilsigtet stor rabat, en refusion på et produkt, de ikke engang købte, en butikskredit, eller hvem ved hvad der ellers.
Mulighederne for misbrug af en webapplikation ved hjælp af Tamper Data er uendelige. Hvis jeg var en softwareudvikler, ville det bare holde mig om natten at vide, at der findes værktøjer som Tamper Data derude.
På flip-siden er Tamper Data et fremragende værktøj til sikkerhedsbevidste applikationsudviklere at bruge, så de kan se, hvordan deres applikationer reagerer på klientsiden data manipulation angreb.
Udviklere skaber ofte "Brugsager" for at fokusere på, hvordan en bruger vil bruge softwaren til at nå et mål. Desværre ignorerer de ofte den dårlige fyrfaktor. App-udviklere skal sætte på deres dårlige fyrhatte og oprette "Misuse Cases" for at redegøre for hackere ved hjælp af værktøjer som Tamper Data.
Tamper Data bør indgå i deres sikkerhedstest arsenal for at sikre, at klient-side input er valideret og verificeret, før det er tilladt at påvirke transaktioner og server-side processer. Hvis udviklere ikke tager en aktiv rolle i at bruge værktøjer som Tamper Data for at se, hvordan deres applikationer reagerer på angreb, så ved de ikke, hvad de kan forvente og kunne ende med at betale regningen for 60 "Plasma TV, som hackeren lige har købt til 99 cent ved hjælp af deres defekte indkøbskurv.
