SQL-injections i PHP

Robban skrev:

Dock har väl vissa språk ett visst skydd inbyggt (PHP t.ex. om jag inte minns fel).

Okej, tänkte väll. Jag har provat själv med sql injections på mina egna sidor som är gjorda i php och det har inte funkat. Tur det iaf! :)

Qimen skrev:

Robban skrev:

Dock har väl vissa språk ett visst skydd inbyggt (PHP t.ex. om jag inte minns fel).

Okej, tänkte väll. Jag har provat själv med sql injections på mina egna sidor som är gjorda i php och det har inte funkat. Tur det iaf! :)

Tills någon råkar stänga av magic_quotes ja. Då är det frittfram.

Gulp, kanske ska titta lite mer på det då. :OO :/

Peeer skrev:

Tills någon råkar stänga av magic_quotes ja. Då är det frittfram.

Kan du förklara vad magic_quotes är och vad det gör för ett blåbär på php?? :q

aasah skrev:

Peeer skrev:

Tills någon råkar stänga av magic_quotes ja. Då är det frittfram.

Kan du förklara vad magic_quotes är och vad det gör för ett blåbär på php?? :q

Grovt sett kan man säga att med magic_quotes_gpc satt så kör PHP automatiskt addslashes() på variabler som kommer från länkar, formulär samt cookies.

Peeer skrev:

Tills någon råkar stänga av magic_quotes ja. Då är det frittfram.

Vilket de är från början i PHP >= v4.

spango skrev:

Peeer skrev:

Tills någon råkar stänga av magic_quotes ja. Då är det frittfram.

Vilket de är från början i PHP >= v4.

Default-inställningen är fortfarande att magic_quotes_gpc är satt.

Däremot är den rekommenderade inställningen att det inte ska sättas.

De flesta (om inte alla) webhotell har det satt, och lär väl fortsätta så långt in i framtiden, om de har något säkerhetstänkande. Annars är väl risken stor att vi får se massor av SQL-injections även i PHP-skript.

Peeer skrev:

Qimen skrev:

Robban skrev:

Dock har väl vissa språk ett visst skydd inbyggt (PHP t.ex. om jag inte minns fel).

Okej, tänkte väll. Jag har provat själv med sql injections på mina egna sidor som är gjorda i php och det har inte funkat. Tur det iaf! :)

Tills någon råkar stänga av magic_quotes ja. Då är det frittfram.

Det är därför man gör klokt i att köra funktionen addslashes() manuellt på de okända variabler som skickas till en sql-fråga.

K@llen skrev:

Det är därför man gör klokt i att köra funktionen addslashes() manuellt på de okända variabler som skickas till en sql-fråga.

Och får frågan av sina användare varför de får backslash före sina citationstecken (eftersom maqic_quotes sannolikt är satt).

Antingen får man kolla efter i inställningarna om magic_quotes_gpc är satt, och köra addslashes om det inte är satt.

Eller så får man i sitt skript kolla om det är satt, och om inte köra addslashes.

Detta börjar mer likna en tråd i PHP-forumet :)
och ska vi diskutera vidare de rent tekniska aspekterna i PHP kanske vi ska göra det i PHP-forumet.
Blir lite långtråkigt för icke-PHP-are annars. ;)

Som sagt, denna PHP-diskussion är kanske lite OT.

Och får frågan av sina användare varför de får backslash före sina citationstecken (eftersom maqic_quotes sannolikt är satt).

Men det får de ju ändå om inte stripslashes() körs innan informationen presenteras!?

K@llen skrev:

Och får frågan av sina användare varför de får backslash före sina citationstecken (eftersom maqic_quotes sannolikt är satt).

Men det får de ju ändå om inte stripslashes() körs innan informationen presenteras!?

Och får då frågan av användarna varför deras backslash är bortplockade :)

MySQL strippar backslashes när den lägger in värdet, och du får då en dubbel strip. Hur det är med andra databaser vet jag inte.

Generellt kan man inte säga att man ska köra addslashes. Först måste man kolla om PHP redan gjort detta.
Är man ambitiös gör man detta i sitt skript, och kör addslashes vid behov.
Är man något mindre ambitiös så kollar man i PHP-inställningarna om behovet finns.

Då får man ut det man stoppade in.

MySQL strippar backslashes när den lägger in värdet, och du får då en dubbel strip. Hur det är med andra databaser vet jag inte.

Åfanken, ja, ja där ser man. :r

Tråden delad (php hör hemma i php-forumet)
ursprungstråden

Då borde man kunna göra så här i stället för att vara säker på att addslashes() körs automatiskt men inte dubbelt.

1. Kör aldrig adddlashes() manuellt
2. Lägg in nedanstående kodsnutt överst på alla sidor.

set_magic_quotes_runtime( 1 );

Då borde allt vara som man vill även om man råkar byta till en server som av någon anledning har magic_quotes av?

Det hade varit väldigt smart om det bara hade fungerat. Det fungerar inte när jag testar det på Windows.

Jag förstår heller inte hur det är tänkt att fungera eftersom arrayerna $_GET, $_POST och $_COOKIE redan är satta innan en rad PHP-kod är skriven.

Däremot funkar det att göra så här:

if (!ini_get('magic_quotes_gpc')) {
   foreach ($_POST as $key => $val) {
      $_POST[$key] = addslashes($val);
   }
}

Visserligen är det något krångligare.

Hmm jag satt och skummade lite i några filer till ett Invisionboard. I alla filer så står det:

set_magic_quotes_runtime(0);

Så visst borde det funka att sätta den? :l

Qimen skrev:

Så visst borde det funka att sätta den? :l

Inte när jag provar. Du kan testa själv.

Jag har magic_quotes_gpc satt och testar med följande kod:

<?php  // filnamn: test.php

set_magic_quotes_runtime(0);

echo "<pre>";
print_r($_POST);
echo "</pre>";

?>
<form action="test.php" method="post">
<textarea name="text">hej "hopp"</textarea><br>
<input type="submit">
</form>

Varken på min lokala windowsmaskin eller på webbhotellet kan jag få det att fungera.
Slashes hänger kvar, och det bör de också göra då $_POST-arrayen sätts innan någon kod körts på sidan.

Hmm magic_quotes_runtime verkar inte göra någon skillnad alls. Men sätter man:

magic_quotes_sybase = On

Så kommer de inte med.

Use Sybase-style magic quotes (escape ' with '' instead of \').

Men den verkar man bara kunna påverka genom att ändra i php.ini. :l