php : kan man manipulere med post/server vars?

Tags:    php mysql webserver

<< < 12 > >>
Hey udviklere!
Jeg har et spørgsmål angående sikkerhed, kan man nok godt sige. Jeg kører en hjemmeside hvorpå jeg har nogle kontaktforms og den slags. Derudover ligger tekst fra hjemmesiden i en database. OK. Tekstmæssigt bruger jeg:

Fold kodeboks ind/udPHP kode 


Disse kan selvfølgeligt manipuleres gennem urlen, feks. side.com?parameter_navn = noget. Et alternativ er posts:

Fold kodeboks ind/udPHP kode 


Og mit første spørgsmål er: kan disse manipuleres ud over gennem en form? Lad os feks. sige at den ovenstående variabel er på en side der hedder senddata.php. Lad os sige at den ikke indeholder andet, altså at formen der tilgår den, er på en separat side. Kan jeg gå ind på senddata.php og på en eller anden måde injecte data til den givne variabel?

Mit andet spørgsmål er lidt i forlængelse af det første: den tredje mulighed er at sende data gennem XMLHttpRequest() i JS. Disse data kan feks. modtages med:


Fold kodeboks ind/udPHP kode 


Igen lad os sige at denne variabel findes på siden senddata.php der tilgås fra en anden side. Kan jeg sprøjte data ind i denne variabel ud over med XMLHttpRequest()?

Jeg har selvfølgeligt søgt lidt på google, men jeg har ikke rigtigt kunne finde noget. Mvh.



Indlæg senest redigeret d. 14.10.2017 12:01 af Bruger #21210
16 svar postet i denne tråd vises herunder
0 indlæg har modtaget i alt 0 karma
Sorter efter stemmer Sorter efter dato
Nu er jeg lidt i tvivl om at hvad du mener.
Men det du får i $_POST er noget som PHP får fra gæstens browser og derved styres array af hvad browseren sender til serveren.
Det ville sige at den den server sagtens kan modtage input fra "forme" som ikke eksistere.

Håber dette svarede på dit ene spørgsmål. Den sidste kender jeg intet til :/



Nu er jeg også lidt i tvivl om hvad du helt præcis mener. Du kan godt manipulere en POST variabel med JavaScript. Altså fra klientens/brugerens side kan de sende noget falsk POST data over til en anden side. Men medmindre at de kender dine POST variabler vil de jo bare sende ligegyldig data afsted.

Ved dine forms kunne du jo sikre afsendelsen af dataen. Du kan tage et kig på CSRF beskyttelse: Preventing Cross-Site Request Forgeries (CSRF).

Eksempelvis kan du have en krypteret streng i en variabel, som autogenereres ved hver side. Den bliver så også skrevet til nogle hidden input fields i din form. Du kan så sikre mod at andet data bliver modtaget, hvis ikke disse CSRF variabler bliver modtaget, og stemmer overens med dataen i dit PHP script.



Kort svar er, at ja, alle post/get/cookies/headere/whatever kommer fra brugeren, som kan vælge at manipulere med det hele. Et værktøj, som gør dette nemt, er `curl`, men man kan jo også lave sine egne. Man behøver ikke at begrænse sig til at bruge en browser, og det gør dygtige angribere sjældent.



Som Robert siger, så kan man sagtens manipulere med alt hvad der sendes til serveren.

Du kan bruge det udemærkede gratis produkt, der hedder Postman, til at skubbe alt muligt på din hjemmeside.

Der er flere måder du kan beskytte dig på. Du skal naturligvis lavet en ordenlig kontaktformular, kan lave en honeypot (lave et felt der er skjult for den besøgende, men som en bot ville udfylde) eller bruge CLoudFlare (der koster lidt) foran.




Problemet er at man beder brugeren om alle tilgængelige oplysninger. Derfor skal man som udvikler være kreativ fordi en skjult input og tokens i url er noget som man kan komme uden om. Måske kræver det lidt tid men det kan snydes med.
Derfor er det også vigtigt at man ikke bare tager en løsning og holder fast i den.
Lav så mange sikkerheds løsninger som du kan og håb at de har glemt en af dem og derved falder i fælden.

Jeg har selv en løsning som bruger skjulte input token i url samt navne på input der ændre sig par gang. Lige nu er jeg ved at lave en system som skal prøve at gætte sig til om brugeren er en valid bruger eller om det er en man skal holde øje med :)



Mange tak for svarene, alle sammen!
Jeg undskylder uklarhederne, men det ser ud til at I har ramt rigtigt mht. mit spørgsmål. Christian og Robert: De værktøjer I har nævnt, vil jeg prøve at angribe mig selv med. Det giver tit en go forståelse, synes jeg. Og Daniele: jeg får lige læst artiklen.

Jeg kan lige beskrive min bekymring helt nøjagtigt: Jeg har xml-request på en side, det er vist det samme som AJAX: webMozilla. Denne sender et password til en anden side der modtager med:

Fold kodeboks ind/udPHP kode 


xml sender altså header-info til variablen "PASSWORD", sidste del af HTTP_PASSWORD. Da disse headers sættes med JS, kan en bruger forholdvis nemt se variabelnavnet i koden til siden. Så hvis jeg med noget værktøj kan besøge en php-side og sætte den header med navnet "PASSWORD" til en streng uden at det går gennem en form, har jeg uendeligt mange forsøg på at gætte dette password. Det kan altså bruteforces hvis det er ikke er kompliceret nok.
Jeg er pt. ved at se på curl, og jeg tror at dette kan præcist hvad jeg har beskrevet i min bekymring.



Indlæg senest redigeret d. 19.10.2017 16:54 af Bruger #21210
Som Daniele også nævner så bør du tage et kig på noget "CSRF". (Cross-Site Request Forgeries). Det er ekstremt nemt at sende requests til din server uden brug af din form. Så en af de bedste måder at beskytte sig på, er ved at sende en token med form inputs, som du så tjekker imod ved request fra formen. På den måde ville de skulle gætte en random token, som tilfældigvis er i brug lige nu, og sende med deres requests før de ville kunne få et request igennem. (Det her er en meget kort forklaring af hvordan man kan gøre. Du kan finde meget mere på google/youtube).

Håber det giver mening, og at det var det du var ude efter. Om ikke andet så er det altid en god ting at vide, og token based authentication kan være ret kraftfuldt. Så du kan bruge tokens til rigtig mange nyttige ting. (:

Mvh. Wunder.



I forhold til CSRF er en hemmelig og tilfældig værdi i forms ikke nok, for angriberen kan jo via ajax indlæse formularen og aflæse denne værdi



Pointen med beskeden var ikke at give ham et komplet svar på hvordan han sikre hans hjemmesider. Da det ville kræve lidt mere end en enkelt post på et forum. Idéen var at lede ham i den rigtige retning, så han kan gå ud og lære om det, og derved udvikle sine evner. Derfor virkede det ideelt at starte med noget basalt, som man derefter kan bygge videre på.

Nu bare fordi jeg ikke finder din besked særlig informativ eller konstruktiv. Må jeg så spørge, hvad er din opskrift på "perfekt" sikkerhed? Du lyder til at have nogle holdninger, så på den måde kunne vi måske gå klogere her fra, og din tidligere besked ville ikke være pointless. (:
Mvh. Wunder.



Indlæg senest redigeret d. 28.10.2017 20:48 af Bruger #20949
@WunderStrudel Din post siger ret direkte at det er måden at beskytte sig på, og at det dermed vil kræve, at angriberen gætter et tilfældigt tal. Derfor synes jeg absolut ikke, at det er pointless at sige, at det ikke er tilfældet.

Perfekte løsninger findes svjv ikke, men en god begyndelse er, at bruge HTTP korrekt. Mange lader f.eks. opdateringer ske med GET requests, så noget ala 'http://some.bank.dk/do_something.php?action=transfer-money&from-account=7&to-account=8&amount=100.00' vil overføre penge. Så kan CSRF udføres ved at indsætte et 'img' tag med den pågældende URL. Hvis der kræves en POST eller PUT for at opdatere, så kan det kun ske ved hjælp fra JavaScript.

Men er der dét, så kan man også. Så kan man f.eks. kigge på Origin og/eller Referer headerne. Hvis ikke de indeholder en tilladt host, så dropper man requestet. Browsere er faktisk krævet at skulle levere Origin headeren ved CORS requests, som CSRF er, men jeg ved ikke, om alle browsere overholder det.



Indlæg senest redigeret d. 29.10.2017 14:54 af Bruger #2695
<< < 12 > >>
t