Hack og skjult iframe

Du kan bede brugeren indtaste sit password inden kontoen kan slettes..

Jo... Men det er ikke kun ret_profil-funktionen som han har fundet ud af at misbruge på den måde. Og skulle man gøre det på alle funktionerne, vil det jo til sidst blive et gedemarked af "Indtast password" :(

Det er dig der har kodet det usikkert. En brugers login-status bør tjekkes, valideres og dernæst tildeles et unikt session id.

el_barto > Kan du ikke uddybe?

Den tjekker skam også for at SESSION[id] er sat. Men hvis brugeren går ind på siden, så er SESSION[id] jo stadigvæk sat, og "computeren" tror at brugeren gerne vil slette sin bruger.

<ole>

"Hackeren har lavet en side med en skjult iframe [...]"
- dér ligger dit problem. Sålænge man kan få lov til det, kan du gøre, hvad du vil  :)

/mvh
</bole>

_labisama_

Jeg kan ikke forstå din problemstilling. Hvordan skal en bruger kunne få din konto slettet via. en iframe ?-)

Normalt ville det kræve

login (validering nr. 1)
tryk på link (validering nr. 2)
sletning via. sql (private, dvs. ordnes 100% af php og sql)
en afloggeing af brugeren, da brugerprofilen jo er slettet
header til login side

Hvor ser du et sikkerhedshul ?

Vil det så sige at der ikke er en skid at gøre? Kæmpe bug jo! Så kan man i teorien jo gøre det på alle sider?

Nu hvor jeg har dig Ole, så kig lige her: http://eksperten.dk/spm/611214 :)

Er det muligt at lave en funktion som lige tjekker at brugeren blev sendt fra en side som ligger på mit domæne? Ala: if ($_SERVER['HTTP_REFERER'] == http://www.domæne.dk') { //scritps osv. } else { echo "Du er en hacker! >:("; }

Denne if-sætning virker selvfølgelig ikke... men bare så i forstod det :D

hyber > Fordi iframe åbner siden hvor funktionen slet-bruger findes. SÅ egentlig sletter man sin egen bruger, uden at man ved det.

Se nu her:

<iframe src=http://www.domæne.dk/test.php?action=slet height=0 width=0 frameborder=0></iframe>

På test.php er der en DELETE FROM brugere WHERE id = $_SESSION[id]. Dvs. når du kommer ind på siden så sletter den jo din bruger.

Forstået?

Du skal jo lave et tjeck på om brugeren er logget ind ! Hvis han ikke er det, skal han blive bedt om at indtaste brugernavn og password !

Hvordan finder du ud af om folk er logget ind ? Ud fra den URL siger jo ikke hvem du skal slette ?

Fejlen i det andet spm. har jeg ingen anelse om, hvad er.

Referer-feltet i HTTP-header'en kan enhver ændre, så det kan ikke hæve din sikkerhed. Det, der kan gøre en forskel, er at stoppe hullet, så man ikke kan lave den slags dokumenter på din server.

Til Jer andre: Brugeren _er_ logget ind, når det sker. Han kommer uforvarende til at slette sin egen bruger, da der ligger en skjult iframe i et dokument - og denne iframe loader labisma's script til at slette brugere med  :)

leif > Nej det siger urlen ikke... men når man havner på siden, så laver den DELETE FROM... som jeg også skrev nedenunder...

Jeg tjekker sådan øverst:

<? session_start();

if ($_SESSION["id"] == '') {
Header("Location:../?action=session");
exit;
} else { ?>

"Det, der kan gøre en forskel, er at stoppe hullet, så man ikke kan lave den slags dokumenter på din server."

Kunne jeg godt tænke mig at vide mere om :)

Bare lige for at være sikker ! Dvs. på sin side kan man selv lave sin egen lille brugerside hvor man kan bruge iframe ?

Nej leif! (Lød som en dårlig sonofon reklame) :)

Jeg har selvfølgelig brugt strip_tags, htmlenities osv. Men hvis du er logget ind, og en person skriver en besked at du skal gå ind på: www.hackers_er_dumme.dk/hack.php og så får du en MASSE penge, så kan brugerne blive fristet til at trykke på linket, og så bliver deres brugere jo slettet! :(

Ahhh, på den måde !

Og så var der dødt? :(

Måske noget i denne til kan forbedre sikkerheden. Følgende metode kan forhindre et direkte kald til process.php

--- html form

<?php
$submit_id = <generer tilfældigt id>;
$_SESSION['submit_id'] = $submit_id;
?>
<form action="process.php">
<input type="hidden" name="session_id" value="<?=$submit_id?>">
</form>

--- process.php

<?php
if($_SESSION['submit_id'] != $_POST['submit_id']){
    // sorry
    exit();
}
?>


--- samme metode kan bruges ved links.. rediger_slet_profil.php:

<a href="slet_profil.php?submit_id=$submit_id">slet profil</a>

Dvs siden hvor linket præsenteres SKAL loades først for at få et korrekt id

Nej, der er ikke nogen, der er døde ... der er tværtimod nogen, der lever - også udenfor Ekspertens lyseblå univers  :)

- og nej, ranglens forslag forhindrer intet. 'Hackerens' nuværende 'angrebsmetode' vil banke lige igennem, uden du aner, hvad der ramte dig. Man kan ikke gøre noget tilnærmelsesvist sikkert uden at checke alle bruger-input i hoved og r..  ;o)

Så længe man benytter sig af HTTP-protokollen er det svært at gøre alt helt sikkert (selvom man kan gøre meget). Det mest sikre er, hvis du selv er server administrator og har mere end én server til rådighed - men det gælder de færreste.

Derudover skal du forvente, 'hackeren' sidder og læser med her. I så fald læser han også alle de _næsten_ sikre features, du infører - og ved derfor, hvordan han skal komme udenom dem. Det kan måske også afholde visse fra at give gode råd - da det samtidig kan give idéer til kompromitering af sites, den pågældende svarer har haft med at gøre  :)

Én rimelig sikker metode er dog at lade f.eks. ændringer i brugerprofilen ske i en temporær tabel, hvor man også indsætter en unik ID. Samtidig skyder man en mail af til brugeren med et link til et konfirmations dokument - og med en forklaring om, at nogen har forsøgt at rette profilen:
  http://www.domain.dk/confirm_user.php?uniqID=ma7uyl14ghfjhg5hjkh456wqps4

Hvis brugeren er i stand til at logge sig ind og de to ID'er stemmer overens, er der temmelig god sandsynlighed for, det er den rigtige bruger, der retter/sletter sin profil.

- og da vi ved, der tale om den rigtige bruger, overskriver vi data i den alm. brugertabel med data fra den temporære - og sletter efterfølgende disse.
Det fik jeg vist ikke helt pindet ud i den forgående kommentar  :)

ole, hvad med du ikke den metode ikke beskytter? Den metode beskytter præcis i mod at lave en sådan en iframe..

<iframe src="sletprofil.php">

den går ikke længere, da korrekt id ikke vil være genereret..

Jeg tror nu nok at ranglen's forslag burde virke. Synes bare det er lidt omfattenede at lave stortset alle links på hjemmesiden med en unik-kode :)

Jeg har lige brygget et hurtigt eksempel sammen
http://squashguy.1go.dk/secure.php

For at kunne opdatere eller slette profilen, skal der submittes en korrekt token.

ole, mener du så jeg har overset noget? For at hackeren kan lave en ekstern side og omdirigere brugeren, er det jo påkrævet at hackeren gætter hvilken token som ligger i brugerens session..

(Vi antager at cross side scripting ikke længere er muligt)

Hvem vil have points? :D