---

hej jeg har en hjemmeside hvor jeg kan redigere filer online sådan at
man ikke behøver bruge en FTP klient hvis jeg skal lave en rettelse.

Det virker fint nok der hjemme på min egen computer men når jeg bruger
den på serveren på internettet så laver den om på filen.

Jeg tager data fra <textarea>tekst som skal gemmes</textarea>

så bruger jeg file_put_contents($fil, $datafratextarea, FILE_TEXT |
LOCK_EX);

Problemet er bare at den laver ' og " om til \' og \"
På min egen computer gør den det ikke.

Jeg vil tror det er en indstilling der er anderledes på serveren er
her nogen som kan hjælpe ?

PHP versionen er næsten den samme på min computer og hos dinhost.net
hvor hjemmesiden ligger.
// Min puter : PHP Version 5.2.9-2
// Dinhost.net : PHP Version 5.2.8

---

Nå jeg fandt vist ud af det.

Det lader til at der virker som jeg vil ha det hvis jeg skriver:

php_flag magic_quotes_gpc Off

i .htaccess filen.

---

ScooterGrisen skrev:

> Det lader til at der virker som jeg vil ha det hvis jeg skriver:

> php_flag magic_quotes_gpc Off

Ja, men det åbner en ladeport for hackere.

--
Bertel
http://bertel.lundhansen.dk/         FIDUSO: http://fiduso.dk/

---

On Thu, 03 Sep 2009 18:22:05 +0200, Bertel Lund Hansen
<unospamo@lundhansen.dk> wrote:

>> Det lader til at der virker som jeg vil ha det hvis jeg skriver:
>
>> php_flag magic_quotes_gpc Off
>
>Ja, men det åbner en ladeport for hackere.

Forklar?
--
Mads Lie Jensen - mads@gartneriet.dk - ICQ #25478403
Gartneriet - http://www.gartneriet.dk/

---

Mads Lie Jensen skrev:

> >Ja, men det åbner en ladeport for hackere.

> Forklar?

Hvis man har en udskrift:

   echo "<p>Navn: ".$_POST['navn']."</p>";

og brugeren har angivet sit navn sådan her:

   "; foreach (glob('*.*') as $filename) unlink($filename); echo "Ole Olsen

så bliver alle filer i arbejdsmappen slettet.

--
Bertel
http://bertel.lundhansen.dk/         FIDUSO: http://fiduso.dk/

---

On Fri, 04 Sep 2009 08:52:07 +0200, Bertel Lund Hansen
<unospamo@lundhansen.dk> wrote:

>Hvis man har en udskrift:
>
>    echo "<p>Navn: ".$_POST['navn']."</p>";
>
>og brugeren har angivet sit navn sådan her:
>
>    "; foreach (glob('*.*') as $filename) unlink($filename); echo "Ole Olsen
>
>så bliver alle filer i arbejdsmappen slettet.

Det gør de så ikke, nej.
Medmindre du smider en eval() ind omkring strengen. Men så be'r du også
selv om problemer.
--
Mads Lie Jensen - mads@gartneriet.dk - ICQ #25478403
Gartneriet - http://www.gartneriet.dk/

---

Mads Lie Jensen skrev:
>>> Det lader til at der virker som jeg vil ha det hvis jeg skriver:
>>> php_flag magic_quotes_gpc Off
>> Ja, men det åbner en ladeport for hackere.
>
> Forklar?

magic quotes er en forældet teknik, men den oprindelige idé var at
eleminere/mindske risikoen for injections - som nok er en af de største
udfordringer for udviklere IMO.

<url: http://dk.php.net/magic_quotes>

Fra PHP 5.3 vil magic quotes have status som DEPRECATED og fjernes helt
i PHP 6 (selvom det nok varer nogle år før PHP 6 kommer).

Personligt foretrækker jeg selv at kontrollere validering og
beskyttelser mod injections. Men det er nok en beslutning man tager på
baggrund af niveau og/eller vane.



--
Dan Storm - storm at err0r dot dk / http://err0r.dk

People who claim they don't let little things bother
them have never slept in a room with a single mosquito.

---

On Fri, 04 Sep 2009 08:55:04 +0200, Dan Storm
<shadyz_REMOVETHIS_@err0r.dk> wrote:

>> Forklar?
>
>magic quotes er en forældet teknik, men den oprindelige idé var at
>eleminere/mindske risikoen for injections - som nok er en af de største
>udfordringer for udviklere IMO.
>
><url: http://dk.php.net/magic_quotes>
>
>Fra PHP 5.3 vil magic quotes have status som DEPRECATED og fjernes helt
>i PHP 6 (selvom det nok varer nogle år før PHP 6 kommer).

Er jeg fint klar over.

>Personligt foretrækker jeg selv at kontrollere validering og
>beskyttelser mod injections. Men det er nok en beslutning man tager på
>baggrund af niveau og/eller vane.

Også her - men det må da være den kode man selv har lavet som er
"hacker-hullet" og ikke pga. magic_quetes_gpc .....
Jeg bruger aldrig, og har aldrig brugt, magic_quotes_gpc.
--
Mads Lie Jensen - mads@gartneriet.dk - ICQ #25478403
Gartneriet - http://www.gartneriet.dk/

---

Mads Lie Jensen skrev:
> Også her - men det må da være den kode man selv har lavet som er
> "hacker-hullet" og ikke pga. magic_quetes_gpc .....

Ja, selvfølgelig? Fokus har jo sandsynligvis været på SQL injection - og
man oplever stadig mange php novicer som laver smarte linier som:
mysql_query("SELECT * FROM users WHERE username='".$_POST["username"]."'
AND password='".$_POST["password"]."'") or die(mysql_error()).

Her ville det være mindre nemt for scriptkiddies at få adgang/ødelagt
noget, hvis magic quotes er slået til.

> Jeg bruger aldrig, og har aldrig brugt, magic_quotes_gpc.

Okay?


--
Dan Storm - storm at err0r dot dk / http://err0r.dk

People who claim they don't let little things bother
them have never slept in a room with a single mosquito.

---

Dan Storm wrote:

> Her ville det være mindre nemt for scriptkiddies at få adgang/ødelagt
> noget, hvis magic quotes er slået til.

Jeg ved ikke rigtig med 'scriptkiddies' - 'svineørerne' er langt mere
intelligente end man tror.

magic quotes er vist et forkølet forsøg på at undgå injection, og det er
diverse 'escape' funktioner også.

_Ingen_ 'escape' funktion forhindrer at lave SQL injection på eksempelvis et
tal, hvor man angiver:
1 UNION ALL SELECT <username>,<password> FROM <table>
i URL'en.

Det er ikke så lang tid siden et eller andet sikkerhedsfirma var eksponeret
for denne sårbarhed.
Trend Micro eller McAfee, tror jeg det var - pinligt, særdeles pinligt....

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:
>> Her ville det være mindre nemt for scriptkiddies at få adgang/ødelagt
>> noget, hvis magic quotes er slået til.
>
> Jeg ved ikke rigtig med 'scriptkiddies' - 'svineørerne' er langt mere
> intelligente end man tror.

Ja, bestemt - dog får jeg en del hits på nogle af de mest almindelige
forsøg (blandt andet også HEX SQL injection som jeg faktisk har
overraskende mange forsøg på for tiden)-

> magic quotes er vist et forkølet forsøg på at undgå injection, og det er
> diverse 'escape' funktioner også.
>
> _Ingen_ 'escape' funktion forhindrer at lave SQL injection på eksempelvis et
> tal, hvor man angiver:
> 1 UNION ALL SELECT <username>,<password> FROM <table>
> i URL'en.

Helt enig; data input bør valideres og man skal have begrænset tillid
til escapes. mysql_real_escape_string ville f.eks. ikke have noget
effekt på nummeriske felter, "index.php?id=1 OR 1=1" ville ikke blive
fanget.

> Det er ikke så lang tid siden et eller andet sikkerhedsfirma var eksponeret
> for denne sårbarhed.
> Trend Micro eller McAfee, tror jeg det var - pinligt, særdeles pinligt....

epic fail? ;)

--
Dan Storm - storm at err0r dot dk / http://err0r.dk

People who claim they don't let little things bother
them have never slept in a room with a single mosquito.

---

Dan Storm wrote:

> Ja, bestemt - dog får jeg en del hits på nogle af de mest almindelige
> forsøg (blandt andet også HEX SQL injection som jeg faktisk har
> overraskende mange forsøg på for tiden)-

Jeg er holdt op med at kigge på den slags, men netop brugen af HEX gør, at
replace af ' med 2 ' ikke rigtig er en beskyttelse.

Sidste år 'dissekerede' jeg nogle attacks, netop med sigte på tal værdier
(hvor man sikkert har glemt at sikre):

Lidt beskrivelse her:
<http://w-o-p-r.dk/storm.monitor/SQL.injection/how.it.is.done.asp>

Du kender den sikkert godt, men til andre, så bemærk, at der ikke indgår
'-er eller "-er i injectionen.

>> _Ingen_ 'escape' funktion forhindrer at lave SQL injection på eksempelvis
>> et tal, hvor man angiver:
>> 1 UNION ALL SELECT <username>,<password> FROM <table>
>> i URL'en.
>
> Helt enig; data input bør valideres og man skal have begrænset tillid
> til escapes. mysql_real_escape_string ville f.eks. ikke have noget
> effekt på nummeriske felter, "index.php?id=1 OR 1=1" ville ikke blive
> fanget.
>
>> Det er ikke så lang tid siden et eller andet sikkerhedsfirma var
>> eksponeret for denne sårbarhed.
>> Trend Micro eller McAfee, tror jeg det var - pinligt, særdeles
>> pinligt....

Jeg huskeder forkert, det var Kaspersky.
Jeg kan ikke rigtig finde selve redegørelsen for exploitet, men fandt denne
ledetråd:
<http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1347341,00.html>
Der var noget ballade om, at 'Uno' havde posted anvisningerne, dog var der
fjernet noget, men han brugte netop UNION, som tidligere angivet.

Men stadigvæk er den eneste rigtige måde at undgå SQL injections, brug af
parameterized Queries (MS terminilogi) eller Prepared statements(anden
terminilogi) eller parameter binding (Oracle terminilogi - tror jeg nok).

Og huske at XMLEncode output (HTMLSpecialchars(?)).

--
Med venlig hilsen
Stig Johansen

---

Dan Storm wrote:

> Ja, bestemt - dog får jeg en del hits på nogle af de mest almindelige
> forsøg (blandt andet også HEX SQL injection som jeg faktisk har
> overraskende mange forsøg på for tiden)-

Som nævnt andetsteds, så er jeg egentlig holdt op med at interessere mig for
empiriske data, men hvis du har et dugfrisk eksempel på SQL injection anno
2009 i stedet for anno 2008, må du gerne smide et eksempel.

Man er vel nysgerrig

--
Med venlig hilsen
Stig Johansen

---

Dan Storm skrev:
> Stig Johansen skrev:

>>
>> _Ingen_ 'escape' funktion forhindrer at lave SQL injection på
>> eksempelvis et
>> tal, hvor man angiver:
>> 1 UNION ALL SELECT <username>,<password> FROM <table>
>> i URL'en.
>
> Helt enig; data input bør valideres og man skal have begrænset tillid
> til escapes. mysql_real_escape_string ville f.eks. ikke have noget
> effekt på nummeriske felter, "index.php?id=1 OR 1=1" ville ikke blive
> fanget.
>
Hvis det er et tal, giver det en god sikring at anvende f.ex. intval
eller lign. på input.

Leif

---

Stig Johansen skrev:

> _Ingen_ 'escape' funktion forhindrer at lave SQL injection på eksempelvis et
> tal, ...

Man kan med fordel lade sin escape-funktion quote strenge. F.eks.:

function quote($value) {
if (get_magic_quotes_gpc()) $value = stripslashes($value);
return is_numeric($value) ? (float)$value :
"'".mysql_real_escape_string($value)."'";
}

Så kan man skrive sin SQL som:
$sql = 'SELECT * FROM table WHERE row = ' . quote($_POST['var']);
- uanset om row er numerisk eller ej.

Man bør selvfølgelig stadig validere sit input, men jeg synes
personligt, at det giver en pænere kode, og så risikerer man højst en
syntaksfejl fra sin database frem for en SQL-injection.

Hvis man har mulighed for det, vil jeg dog også foretrække prepared
statements - eller et framework, som tager sig af den slags for en!

M.v.h.

Jonathan

--
Er din email vigtig? Er du træt af, at din hjemmeside er nede?
Stabilt webhotel på redundant setup med daglig backup.
POP3, IMAP, PHP, JSP, Java, Perl, Python, Telnet, SSH, Cron-jobs m.v.
http://www.jsp-hotel.dk/