mboost-dp1
PHP / html pis
Mojn,
Jeg har et array med en bunke data fra en database, der bliver udskrevet på en hjemmeside. Ganske standard.
Jeg vil gerne, ud for hver linje, have en 'slet'-knap, der sletter den specifikke linje i databasen.
Jeg har dette pt:
http://pastebin.com/jBVu0erq
Jeg har fjernet en masse formatering osv. fra ovenstående, så skulle der være en syntaksfejl eller to er det derfor.
Problemer er, at når jeg trykker 'Slet' og kommer ned i isset($_POST['slet']), så tager den ID'et fra den sidste entry i arrayet.. hvilket jo giver god mening.
Mit spørgsmål er - hvordan kan jeg sørge for at det er linje Y (den valgte) der bliver slettet, selvom der er X linjer?
Jeg har et array med en bunke data fra en database, der bliver udskrevet på en hjemmeside. Ganske standard.
Jeg vil gerne, ud for hver linje, have en 'slet'-knap, der sletter den specifikke linje i databasen.
Jeg har dette pt:
http://pastebin.com/jBVu0erq
Jeg har fjernet en masse formatering osv. fra ovenstående, så skulle der være en syntaksfejl eller to er det derfor.
Problemer er, at når jeg trykker 'Slet' og kommer ned i isset($_POST['slet']), så tager den ID'et fra den sidste entry i arrayet.. hvilket jo giver god mening.
Mit spørgsmål er - hvordan kan jeg sørge for at det er linje Y (den valgte) der bliver slettet, selvom der er X linjer?
Jeg har denne form.
Jeg er absolut ikke php/html-mand, så du er nødt til at skære det ud i pap, hvis jeg skal ændre noget til $_GET istedet. D:
<form id="slet" method="post" action="">
<input type="hidden" name="slet" id="news" value="<?php print $var['newsid']?>"/>
</form>
Jeg er absolut ikke php/html-mand, så du er nødt til at skære det ud i pap, hvis jeg skal ændre noget til $_GET istedet. D:
For at gøre det nemt for dig selv, så vil jeg som før nævnt, lave det om til bare at være et link. Så dine links vil være noget ala href="?slet=$newsid"
Så skal du ikke have nogen form eller javascript.
Hvis du så laver din $_POST om til $_GET, vil du hente ID'et ud fra URL'en, som du så kan slette ud fra.
Så skal du ikke have nogen form eller javascript.
Hvis du så laver din $_POST om til $_GET, vil du hente ID'et ud fra URL'en, som du så kan slette ud fra.
#6
Det er en intern side der kræver password-adgang, så det går nok. Det er ikke noget vigtigt, der kommer til at blive skrevet (det er ting som "der er kage i dag", "blabla er syg" osv.), så problemet er til at overse :D
Især fordi der kun er én der vil kunne finde ud af det trick - mig.
Det er en intern side der kræver password-adgang, så det går nok. Det er ikke noget vigtigt, der kommer til at blive skrevet (det er ting som "der er kage i dag", "blabla er syg" osv.), så problemet er til at overse :D
Især fordi der kun er én der vil kunne finde ud af det trick - mig.
Hvis din browser er logget på den interne side samtidigt med at den har en ekstern webside åben, så kan hullet udnyttes.XorpiZ (7) skrev:Det er en intern side der kræver password-adgang, så det går nok.
Jeg tror du undervurderer risikoen. Der er mange måder hvorpå en intern URL kan lække. Og nogle gange er kendskab til URLen nok til at man kan finde ud af, hvordan hullet udnyttes.XorpiZ (7) skrev:Især fordi der kun er én der vil kunne finde ud af det trick - mig.
Jep. Det var f.eks. tilfældet med et hul jeg fandt for godt to år siden: http://newz.dk/forum/tagwall/sikkerhedshul-hos-dan...arne_v (9) skrev:Det behøver ikke engang være et link der skal klikkes på. En IMG SRC kan gøre det.
Det minder mig om at jeg skal have fulgt op på to andre sikkerhedshuller, jeg fandt i nogle andre IT systemer for nyligt. Med det antal huller jeg finder helt uden at kigge efter dem, så frygter jeg lidt for hvor mange der ligger gemt, hvis man rent faktisk begyndte at lede.
kasperd (10) skrev:Hvis din browser er logget på den interne side samtidigt med at den har en ekstern webside åben, så kan hullet udnyttes.
Huh. Det var satans. Det troede jeg faktisk ikke.
kasperd (10) skrev:Jeg tror du undervurderer risikoen. Der er mange måder hvorpå en intern URL kan lække. Og nogle gange er kendskab til URLen nok til at man kan finde ud af, hvordan hullet udnyttes.
Det er muligt. Dog er problemet ikke større end, at det eneste de kan slette er ligegyldige beskeder om hvem der har kage med, hvem der er syg og hvem der går tidligt.
Det sagt, så er jeg dog ganske interesseret i at høre hvordan man bør beskytte sig mod den slags!
#11
Hvis du sætter serveren til at sende en tilfældig genereret nøgle med til klienten, så er sidens form unik.
Udefrakommende vil ikke kunne gætte sig frem til denne nøgle.
Når klienten så submit'er, så skal serveren teste, at klienten sender en gyldig nøgle med tilbage. Serveren skal altså huske hvilke nøgler den har givet. Det kan gøres rimelig nemt via en session.
Hvis du sætter serveren til at sende en tilfældig genereret nøgle med til klienten, så er sidens form unik.
Udefrakommende vil ikke kunne gætte sig frem til denne nøgle.
Når klienten så submit'er, så skal serveren teste, at klienten sender en gyldig nøgle med tilbage. Serveren skal altså huske hvilke nøgler den har givet. Det kan gøres rimelig nemt via en session.
kasperd (10) skrev:Hvis din browser er logget på den interne side samtidigt med at den har en ekstern webside åben, så kan hullet udnyttes.
XorpiZ (11) skrev:Huh. Det var satans. Det troede jeg faktisk ikke.
Det er lidt mere komplekst end som så:
Hvis session maintaines via URL rewriting er det ikke et problem.
Hvis session maintaines via session cookie afhænger det af browser og om det er to tabs eller to vinduer.
Langt de fleste sites bruger session cookies fremfor URL rewriting (og bemærk at URL rewriting har andre sikkerhedsmæssige problemer).
Jeg er ikke up to date med hensyn til browser opførsel, men som jeg husker det for år tilbage så:
- delte både FF og IE session cookie mellem 2 tabs
- en af FF og IE delte session cookie mellem 2 vinduer og en gjorde ikke
Det kan klart anbefales at designed udfra worst case.
XorpiZ (11) skrev:Det sagt, så er jeg dog ganske interesseret i at høre hvordan man bør beskytte sig mod den slags!
Første trin må være at bruge POST fremfor GET.
m910q (12) skrev:#11
Hvis du sætter serveren til at sende en tilfældig genereret nøgle med til klienten, så er sidens form unik.
Udefrakommende vil ikke kunne gætte sig frem til denne nøgle.
Når klienten så submit'er, så skal serveren teste, at klienten sender en gyldig nøgle med tilbage. Serveren skal altså huske hvilke nøgler den har givet. Det kan gøres rimelig nemt via en session.
Det er rigtigt godt. Men noget nemmere hvis man kan bruge et framework, så man ikke skal ind og håndkode det overalt.
Det i sig selv beskytter dog ikke. Det er ikke specielt svært at få en browser til a poste en form til et andet site.arne_v (14) skrev:Første trin må være at bruge POST fremfor GET.
Man skal både bruge POST og tilføje en hemmelig værdi til hver form, sådan som #11 forklarer. Altså noget i retning af: <input name="xsrf-protection" type="hidden" value="oDcV6laKtbyvbK3UHc1BsOk2Wz1Qkh3A" />
Det er helt bestemt en god idé. Hvis det håndkodes overalt, så er det nemt at glemme et sted. Jeg har selv arbejdet en del med django på det seneste, og det kan sættes op så alle POST requests kræver den hemmelige værdi som default. Hvis man glemmer at få feltet med i en form, så får browseren en fejlmelding helt uden at ens egen kode bliver kørt på serveren.arne_v (14) skrev:Det er rigtigt godt. Men noget nemmere hvis man kan bruge et framework, så man ikke skal ind og håndkode det overalt.
Jeg er fuldstændigt enig i at man bør anvende POST til den slags requests. Hvis en request ændrer state på serveren, så er GET den forkerte metode.arne_v (16) skrev:Det er ikke tilstrækkeligt til at gøre det sikkert.
Men jeg vil stadig anbefale det.
Men lige netop overfor XSRF angreb er der kun en beskeden forbedring af sikkerheden ved at skifte fra GET til POST, mens en hemmelig værdi i en af request parametrene faktisk giver en reel beskyttelse imod den klasse af angreb.
Hemmelige værdier bør til gengæld aldrig sendes med GET, hvis det kan undgås. Så det er endnu et argument for at bruge POST. En værdi som er sendt i en GET parameter er som regel at finde i en logfil og kan nemt risikere at dukke op i referer headers som kan ende i en logfil på en tredjeparts server.
Sidstnævnte type hul fandt jeg også et af for nyligt, da jeg var ved at kigge på en webserver log. Der opdagede jeg pludseligt en referer i loggen med en hemmelig værdi fra et site, jeg ellers intet har at gøre med.
Det skader som regel ikke at checke referer headeren på de POST requests man modtager og afvise dem, hvis referer er forkert. Men eftersom man alligevel er nødt til at have en løsning til alle de requests, som ikke har en referer header, så er det måske ikke værd at bruge tid på check af referer header.m910q (18) skrev:Men det er selvfølgelig stadig muligt, at lave checket, på dem der gør.
Afviser man alle POST requests uden referer header, så risikerer man at afvise legitime requests. Accepterer man alle POST requests uden referer header, så er man nødt til at have en anden beskyttelse imod XSRF.
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund