[PHP/(My)SQL] voor dummies - Deel 12

Index

» digital corner

actieve topics nieuwe topics
abonnement Unibet Coolblue Bitvavo
pi_29997266
quote:
Op vrijdag 26 augustus 2005 11:53 schreef BarteS het volgende:
Ik heb een query, $result genaamd
Ik heb een fetch, mysql_fetch_array($result, MYSQL_ASSOC)

Nu wil ik dat in de tussentijd $result leeggemaakt word, op een dusdanige manier dat de fetch niet gaat protesteren met de melding: "Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource "
Je wilt dus de resultset leegmaken, en deze vervolgens ophalen?

Of als je gewoon wilt dat mysql_fetch_array (of beter: mysql_fetch_assoc, zoals in de laatste post van het vorige topic stond) geen foutmelding geeft, dan doe je dit:

1
2
3		<?php
$data = @mysql_fetch_assoc($result);  //geen resource? geen foutmelding!
?>
pi_30024981
Ik wil graag een error handler maken voor mn mysql queries. Die error moet dan in een file worden geschreven, is er een mogelijkheid om uit te vinden op welke regel in het script de foute query staat?
Vogelaars.nl
pi_30025296
__LINE__ The current line number of the file.
__FILE__ The full path and filename of the file.
__FUNCTION__ The function name. (This was added in PHP 4.3.0.)
__CLASS__ The class name. (This was added in PHP 4.3.0.)
__METHOD__ The class method name. (This was added in PHP 5.0.0)

bron
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
pi_30056095
Heeft iemand goede tutorials over het gebruik van PHP en InnoDB? Ik wil hier het een en ander mee gaan stoeien, maar ik kan niet echt een tutorial erover vinden.

Maw: Hoe voer ik een query uit, hoe geef ik start, commit of roleback mee etc.
pi_30056191
quote:
Op zaterdag 27 augustus 2005 12:26 schreef ikke_ook het volgende:
Ik wil graag een error handler maken voor mn mysql queries. Die error moet dan in een file worden geschreven, is er een mogelijkheid om uit te vinden op welke regel in het script de foute query staat?
Iets wat ik vaak bij error handlers gebruik: debug_backtrace()
pi_30058019
quote:
Op zondag 28 augustus 2005 15:59 schreef JeRa het volgende:

[..]

Iets wat ik vaak bij error handlers gebruik: debug_backtrace()
Dat is ook wel handig eigenlijk alhoewel dat van SR er erg veel op lijkt, bedankt beiden
Vogelaars.nl
  FOK!-Schrikkelbaas maandag 29 augustus 2005 @ 21:53:21 #8
1972 Swetsenegger
Egocentrische Narcist
pi_30078412
Waarom zet hij mijn cookie niet?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31		<?php
if ($_SERVER['REQUEST_METHOD']=='POST'){

$password=md5($_POST['password']);

$query='SELECT * FROM user WHERE user="'.$_POST['user'].'" && password="'.$password.'"';
$result=mysql_query($query);
$row=mysql_fetch_array($result);

if(mysql_num_rows($result) != 0){
  if($row['activated']!='0'){

                session_start();
                $_SESSION['IP']=$_SERVER["REMOTE_ADDR"];
                $_SESSION['name']=$row['name'];
                $_SESSION['login']='1';
                header("Location: ../".$_POST['location']."");
                                        

                                }else{
                                $login="<span style=\"color:red;\">U kunt pas inloggen als uw account is geactiveerd</span>";
                                setcookie('posted',$login);
                                header("Location: ../".$_POST['location']."");
                                }
                                }else{
                                $login="<span style=\"color:red;\">Ongeldige inlog</span>";
                                setcookie('posted',$login);
                                header("Location: ../".$_POST['location']."");
                                }
}
?>


Indien ik dus een verkeerde login opgeef, werkt de header wel, maar mijn cookie is leeg.
Wat doe ik fout?
 | FOK! Schrikkelbaasch
  FOK!-Schrikkelbaas maandag 29 augustus 2005 @ 22:13:22 #9
1972 Swetsenegger
Egocentrische Narcist
pi_30079177
Even een testje gemaakt, cookie heeft nu WEL waarde, maar is deze dus na de header kwijt.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21		<?php
if(mysql_num_rows($result) != 0){
  if($row['activated']!='0'){
                session_start();
                $_SESSION['IP']=$_SERVER["REMOTE_ADDR"];
                $_SESSION['name']=$row['name'];
                $_SESSION['login']='1';
                header("Location: ../".$_POST['location']."");
                                }else{
                                $login="<span style=\"color:red;\">U kunt pas inloggen als uw account is geactiveerd</span>";
                                setcookie('posted',$login);
                                header("Location: ../".$_POST['location']."");
                                }
                                }else{
                                setcookie('posted','<span style="color:red;">Ongeldige inlog</span>');
                                echo $_COOKIE['posted'];
                                die();
                                //header("Location: ../".$_POST['location']);
                                }
}
?>
 | FOK! Schrikkelbaasch
  FOK!-Schrikkelbaas maandag 29 augustus 2005 @ 22:40:49 #10
1972 Swetsenegger
Egocentrische Narcist
pi_30080262
path dus

*zucht*

domdomdom... path dus

1
2
3		<?php
setcookie('posted',$login,'','/');
?>
 | FOK! Schrikkelbaasch
pi_30080375
quote:
Op maandag 29 augustus 2005 22:40 schreef Swetsenegger het volgende:
path dus

*zucht*

domdomdom... path dus
[ code verwijderd ]
Houd je er dan ook rekening mee dat expire (de derde parameter) een integer moet zijn?
fokstok.nl
  FOK!-Schrikkelbaas maandag 29 augustus 2005 @ 23:38:59 #12
1972 Swetsenegger
Egocentrische Narcist
pi_30082462
quote:
Op maandag 29 augustus 2005 22:43 schreef Light het volgende:

[..]

Houd je er dan ook rekening mee dat expire (de derde parameter) een integer moet zijn?
cookie wordt op de volgende pagina uitgelezen en direct getrashed. Daarom stel ik geen expiration in
 | FOK! Schrikkelbaasch
pi_30083899
quote:
Op maandag 29 augustus 2005 23:38 schreef Swetsenegger het volgende:

[..]

cookie wordt op de volgende pagina uitgelezen en direct getrashed. Daarom stel ik geen expiration in
Dan kun je alsnog beter 0 dan een lege string gebruiken. Of met sessions gaan spelen natuurlijk.
fokstok.nl
  donderdag 1 september 2005 @ 00:50:08 #14
71919 wonderer
Hung like a My Little Pony
pi_30152785
Ik heb een streaming chat in PHP die prima werkt. Nu wil ik hem op een andere server installeren, maar hij werkt niet, en ik weet niet waar het aan ligt. Ik ben er inmiddels achter dat het de stream functie is die last geeft, en die werkt met ob_implicit_flush();

De werkende heeft PHP versie 4.3.11, de nietwerkende 4.3.10. Verder is de config nagenoeg gelijk, hoewel session.use_trans_sid (genoemd als probleem bij ob_implicit_flush) bij de niet-werkende aan staat en bij de werkende uit. Ik ben niet zo thuis met ini_set dingen, maar als ik die bovenaan de stream funcie zet, zou dat dan moeten werken?

Of ligt het heel ergens anders aan? Ik vind het erg raar. Hij buffert dus gewoon en output pas als de loop is afgelopen.

Iemand een idee?
"Pain is my friend. I can trust pain. I can trust pain to make my life utterly miserable."
"My brain is too smart for me."
"We don't need no education." "Yes you do, you just used a double negative."
pi_30153055
Buffering is mijns inziens een hel in PHP. Ook al heb je ob_implicit_flush aanstaan, probeer toch eens telkens als je iets output de volgende twee functies aan te roepen:

1
2
3
4		<?php
ob_flush();
flush();
?>
  donderdag 1 september 2005 @ 01:14:21 #16
71919 wonderer
Hung like a My Little Pony
pi_30153290
quote:
Op donderdag 1 september 2005 01:02 schreef JeRa het volgende:
Buffering is mijns inziens een hel in PHP. Ook al heb je ob_implicit_flush aanstaan, probeer toch eens telkens als je iets output de volgende twee functies aan te roepen:
[ code verwijderd ]
Geen verschil. De pagina ziet er schematisch zo uit:

print headers
print html
print de laatste 15 regels
activeer stream -> print regels als ze gezegd worden

Hij print dus niks, ook de eerste drie dingen niet, terwijl het script in principe al drie jaar prima werkt op twee verschillende servers.

Het lijkt wel of de server configuratie het gewoon niet toestaat, maar waar dat dan aan ligt, ik heb geen idee.
"Pain is my friend. I can trust pain. I can trust pain to make my life utterly miserable."
"My brain is too smart for me."
"We don't need no education." "Yes you do, you just used a double negative."
pi_30153616
quote:
Op donderdag 1 september 2005 00:50 schreef wonderer het volgende:

Ik ben niet zo thuis met ini_set dingen, maar als ik die bovenaan de stream funcie zet, zou dat dan moeten werken?
Voor zover ik hier zo kan nagaan doet een ini_set bij session.use_trans_sid niets. Klinkt op zich ook wel logisch, maar het betekent ook dat de enige manier om dit aan te passen is in de server-config. Je zou de suggestie in de php manual kunnen overnemen, dus session_start() weghalen.
fokstok.nl
  donderdag 1 september 2005 @ 01:47:56 #18
71919 wonderer
Hung like a My Little Pony
pi_30153867
session_start uit werkt niet. Dus het moet ergens anders aan liggen...
"Pain is my friend. I can trust pain. I can trust pain to make my life utterly miserable."
"My brain is too smart for me."
"We don't need no education." "Yes you do, you just used a double negative."
pi_30158275
Het probleem kan bij Apache liggen maar ook bij PHP of in je script. Post anders eens wat relevante regels code?
pi_30167519
Ik wil een aantal gegevens ontsluiten naar mensen die onze site bezoeken. Ik heb daarvoor een tweetal tabellen aangemaakt met extra informatie van deze mensen. Ik wil daarvoor het standaard ID wat mysql aanmaakt in tabel users gebruiken waar ik het ID als foreign key wil gebruiken.
Dat is geen probleem, maar hoe kan ik het ID uitlezen op user.html.php???
Ik heb daar een query waar ik het ID aan mee wil geven zodat de juiste mensen de juiste gegevens te zien krijgen.
de boom verbindt in weer en wind de wereld met de wolken om met zijn takken onze groet naar boven te vertolken, waar zij, door ons zo teer bemind het hemelrijk bevolken
pi_30175057
Bedoel je mysql_insert_id?
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
  FOK!-Schrikkelbaas donderdag 1 september 2005 @ 19:52:48 #22
1972 Swetsenegger
Egocentrische Narcist
pi_30176331
quote:
Op donderdag 1 september 2005 15:16 schreef reinierb het volgende:
Ik wil een aantal gegevens ontsluiten naar mensen die onze site bezoeken. Ik heb daarvoor een tweetal tabellen aangemaakt met extra informatie van deze mensen. Ik wil daarvoor het standaard ID wat mysql aanmaakt in tabel users gebruiken waar ik het ID als foreign key wil gebruiken.
Dat is geen probleem, maar hoe kan ik het ID uitlezen op user.html.php???
Ik heb daar een query waar ik het ID aan mee wil geven zodat de juiste mensen de juiste gegevens te zien krijgen.
<a href="user.html.php?id=<?=$gebruikersid;?>">

$query=" SELECT * FROM database WHERE id='".$_GET['id']";

[ Bericht 1% gewijzigd door Swetsenegger op 01-09-2005 20:08:40 ]
 | FOK! Schrikkelbaasch
pi_30176400
Daar gebruiken we natuurlijk niet $_GET direct voor maar op deze manier:

1
2
3
4		<?php
$id = intval($_GET['id']);
$query = 'SELECT * FROM `database` WHERE `id` = ' . $id;
?>

Bij de methode van Swetsenegger heb je kans op een SQL injection.
  FOK!-Schrikkelbaas donderdag 1 september 2005 @ 20:01:20 #24
1972 Swetsenegger
Egocentrische Narcist
pi_30176612
quote:
Op donderdag 1 september 2005 19:55 schreef JeRa het volgende:
Daar gebruiken we natuurlijk niet $_GET direct voor maar op deze manier:
[ code verwijderd ]

Bij de methode van Swetsenegger heb je kans op een SQL injection.
Ik heb het geprobeerd te injecten, en dat lukt echt niet zolang je je data in je query maar tussen ' zet.
En gewoon is_numeric volstaat natuurlijk ook

want laten we het nu eens proberen te injecten
we maken '""DROP TABLE tabel" van de id= in de url.
wat krijgen we dan?

$query="SELECT * FROM table WHERE id=''"DROP TABLE table";

geeft een prachtige sql fout. Maar goed, is_numeric of addslashes

en ow... natuurlijk nooit backticks gebruiken in je query

[ Bericht 9% gewijzigd door Swetsenegger op 01-09-2005 20:06:45 ]
 | FOK! Schrikkelbaasch
pi_30177824
quote:
Op donderdag 1 september 2005 20:01 schreef Swetsenegger het volgende:
en ow... natuurlijk nooit backticks gebruiken in je query
Wat is er mis met backticks?
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
pi_30178200
quote:
Op donderdag 1 september 2005 20:01 schreef Swetsenegger het volgende:

[..]

Ik heb het geprobeerd te injecten, en dat lukt echt niet zolang je je data in je query maar tussen ' zet.
En gewoon is_numeric volstaat natuurlijk ook

want laten we het nu eens proberen te injecten
we maken '""DROP TABLE tabel" van de id= in de url.
wat krijgen we dan?

$query="SELECT * FROM table WHERE id=''"DROP TABLE table";

geeft een prachtige sql fout. Maar goed, is_numeric of addslashes

en ow... natuurlijk nooit backticks gebruiken in je query
SQL injection gaat niet alleen om het droppen van tables, het gaat ook om het vergaren van data die niet rechtmatig is. met een '\' OR 1 OR \'' kun je al veel doen. Bovendien, het is gewoon fout om zomaar user data in een query te stoppen, de 'maar het werkt toch'-beredenering is natuurlijk een van de meest foute een query behoort altijd te werken, ook als de user iets vreemds opgeeft (intval levert in het geval van ongeldige user input gewoon 0 op). Als er tekst van de user moet worden geinserted in een query, behoor je altijd mysqli_real_escape_string te gebruiken. Gebruik je tekst van de user in een query met LIKE, zorg er dan ook voor dat de procenten (%) en de underscores (_) ge-escaped worden want die hebben een speciale betekenis in queries. Dit soort basics zorgen ervoor dat je vanaf het begin een script maakt dat veilig is; zolang je er maar over nadenkt

Natúúrlijk nooit backticks gebruiken, want de verdomd goede reden om dat niet te doen is...?
  FOK!-Schrikkelbaas donderdag 1 september 2005 @ 21:10:36 #27
1972 Swetsenegger
Egocentrische Narcist
pi_30179249
quote:
Op donderdag 1 september 2005 20:46 schreef JeRa het volgende:

[..]

SQL injection gaat niet alleen om het droppen van tables, het gaat ook om het vergaren van data die niet rechtmatig is. met een '\' OR 1 OR \'' kun je al veel doen. Bovendien, het is gewoon fout om zomaar user data in een query te stoppen, de 'maar het werkt toch'-beredenering is natuurlijk een van de meest foute
En dan ook niet mijn redenering. Ik heb voldoende gelezen over injection om te weten dat mijn methode veilig is.
quote:
een query behoort altijd te werken, ook als de user iets vreemds opgeeft (intval levert in het geval van ongeldige user input gewoon 0 op).
Je hoort mij niet zeggen dat dat niet zo is. Als een user wat vreemds in de url propt krijgt hij gewoon netjes een melding dat hij dat niet moet doen.
quote:
Als er tekst van de user moet worden geinserted in een query, behoor je altijd mysqli_real_escape_string te gebruiken. Gebruik je tekst van de user in een query met LIKE, zorg er dan ook voor dat de procenten (%) en de underscores (_) ge-escaped worden want die hebben een speciale betekenis in queries.
Joh....
quote:
Dit soort basics zorgen ervoor dat je vanaf het begin een script maakt dat veilig is; zolang je er maar over nadenkt
En dat doe ik ook. Ik denk dat niemand met 100% zekerheid kan stellen dat zijn script veilig is, maar zolang ik numerieke gets check of ze ook daadwerkelijk numeriek zijn (lijkt me een stuk veiliger dan intval, welke een string gewoon interpreteert als integer en derhalve wel eens meer informatie uit je tabel kan trekken dan voor de user bedoeld was) en ASCII gets gewoon escape is er niets aan de hand. PLUS het feit dat ik mijn data altijd tussen quotes zet in een query, maakt injection redelijk lastig.

In dit geval gaf ik een antwoord op een vraag. Ik hoef toch geen veiligheid tutorial te schrijven bij dit soort vragen?
quote:
Natúúrlijk nooit backticks gebruiken, want de verdomd goede reden om dat niet te doen is...?
backticks zijn een workaround voor beroerde database modellen, waarbij je reserved names als veldnamen gebruikt. Dat moet je gewoon niet doen, en derhalve zijn backticks volledig overbodig. Wanneer je je aanleert geen backticks te gebruiken, zal je dus ook geen reserved words als veldnamen nemen, waardoor je beter hebt nagedacht over je databasde model
 | FOK! Schrikkelbaasch
  FOK!-Schrikkelbaas donderdag 1 september 2005 @ 21:13:07 #28
1972 Swetsenegger
Egocentrische Narcist
pi_30179383
Overigens wel leuk in het licht van deze veiligheids dicussie, een mooi artikel op phpfreakz. Must read
 | FOK! Schrikkelbaasch
  donderdag 1 september 2005 @ 21:15:58 #29
71919 wonderer
Hung like a My Little Pony
pi_30179522
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47		<?php
function stream($kamer,$user)
{
ob_implicit_flush();
$result=runquery("SELECT * FROM $kamer ORDER BY ID DESC LIMIT 0,1");
$row=mysql_fetch_array($result);
$last_ID=$row[ID];

$res=runquery("SELECT * FROM chat_times WHERE chatroom='$kamer' AND username='$user'");
$ro=mysql_fetch_array($res);
$their_time=$ro[said_time];
$now=time();
$diff=$now-$their_time;

$iotime=600; #idle out time

while($diff &lt; $iotime && !connection_aborted()){
$result=runquery("SELECT * FROM $kamer ORDER BY ID DESC LIMIT 0,1");
$row=mysql_fetch_array($result);
$new_ID=$row[ID];
while($new_ID&gt;$last_ID){
  $i=$last_ID+1;
  $result2=runquery("SELECT * FROM $kamer WHERE ID='$i'");
  $row2=mysql_fetch_array($result2);
  $sentence=parse_sentence($row2[sentence],$row2[systemmess]);
  $result3=runquery("SELECT * FROM chat_leden WHERE username='$row2[username]'");
  $row3=mysql_fetch_array($result3);
  $line=lineformat($row2[ID], $row[datum], $row3[access_level], $row2[chatname], $row2[kleur], $sentence, $row2[adminmess], $row2[username]);
  print ($line);
  $line="";
  $last_ID++;
}
if($diff%25&lt;=1){
  $idleline='<!---->';
  print ($idleline);
}
sleep(1);
$rest=runquery("SELECT * FROM chat_times WHERE chatroom='$kamer' AND username='$user'");
$ro=mysql_fetch_array($rest);
$their_time=$ro[said_time];
$now=time();
$diff=$now-$their_time;
}
$line='<b style="color:#ffffff">Je hebt te lang niets gezegd. Klik <a href="display.php?kamer='.$kam.'">HIER</a> om de kamer te herladen</b><script>scroll();</script>';
print ($line);
}
?>


Da's de functie. dingen als "parse sentence" en "lineformat" zorgen er gewoon voor dat de zin leesbaar wordt uitgespuugd.
"Pain is my friend. I can trust pain. I can trust pain to make my life utterly miserable."
"My brain is too smart for me."
"We don't need no education." "Yes you do, you just used a double negative."
pi_30179619
quote:
Op donderdag 1 september 2005 21:10 schreef Swetsenegger het volgende:

[..]

En dan ook niet mijn redenering. Ik heb voldoende gelezen over injection om te weten dat mijn methode veilig is.
Als je checks op je variabele doet, zie ik dat toch echt niet terug als je in een query direct een $_GET element gooit. Mijn opvatting is dat je mensen niet moet aanleren om $_POST of $_GET te vertrouwen, maar dus eerst de user input te valideren
quote:
[..]

backticks zijn een workaround voor beroerde database modellen, waarbij je reserved names als veldnamen gebruikt. Dat moet je gewoon niet doen, en derhalve zijn backticks volledig overbodig. Wanneer je je aanleert geen backticks te gebruiken, zal je dus ook geen reserved words als veldnamen nemen, waardoor je beter hebt nagedacht over je databasde model
Het database model heeft hier dus helemaal niéts mee te maken, hoogstens de naamgeving. En er zijn voorbeelden van database servers die namen als 'e-mail' toestaan maar dit in een query zien als een berekening (vanwege het minteken) en daarop stoppen. In dat geval zijn backticks benodigd (hoewel de meeste DB servers het nu goed doen).
  FOK!-Schrikkelbaas donderdag 1 september 2005 @ 21:26:41 #31
1972 Swetsenegger
Egocentrische Narcist
pi_30180019
quote:
Op donderdag 1 september 2005 21:17 schreef JeRa het volgende:

[..]

Als je checks op je variabele doet, zie ik dat toch echt niet terug als je in een query direct een $_GET element gooit. Mijn opvatting is dat je mensen niet moet aanleren om $_POST of $_GET te vertrouwen, maar dus eerst de user input te valideren
quote:
Op donderdag 1 september 2005 21:10 schreef Swetsenegger het volgende:
In dit geval gaf ik een antwoord op een vraag. Ik hoef toch geen veiligheid tutorial te schrijven bij dit soort vragen?
 | FOK! Schrikkelbaasch
pi_30180454
quote:
Op donderdag 1 september 2005 21:26 schreef Swetsenegger het volgende:

[..]


[..]
Dat is net zoiets als een probleem in Windows oplossen door te zeggen dat je Windows opnieuw moet installeren. Mijn opvatting is dat als het op een andere, betere manier kan, je als scripter die er wat meer verstand van heeft de morele verplichting hebt die zo goed mogelijk te melden anders heb je over twee weken een nieuw topic, 'mijn site is gehacked!11!1'
  FOK!-Schrikkelbaas donderdag 1 september 2005 @ 21:49:02 #33
1972 Swetsenegger
Egocentrische Narcist
pi_30180902
quote:
Op donderdag 1 september 2005 21:36 schreef JeRa het volgende:

[..]

Dat is net zoiets als een probleem in Windows oplossen door te zeggen dat je Windows opnieuw moet installeren.
Bullshit. Porbeer de query welke ik hierboven gaf maar te injecten. Maak maar een voorbeeld scriptje, pleur 'm online en wij gaan met z'n allen proberen 'm te injecten. Safe genoeg voor huis tuin en keuken gebruik.
quote:
Mijn opvatting is dat als het op een andere, betere manier kan, je als scripter die er wat meer verstand van heeft de morele verplichting hebt die zo goed mogelijk te melden anders heb je over twee weken een nieuw topic, 'mijn site is gehacked!11!1'
Ja met die intval is dat risico zeer zeker aanwezig inderdaad. Tenslotte verkomt dat op geen enkele manier dat er data uit de database getrokken kan worden welke niet voor de persoon bedoelt is
 | FOK! Schrikkelbaasch
pi_30181332
quote:
Op donderdag 1 september 2005 21:49 schreef Swetsenegger het volgende:

[..]

Bullshit. Porbeer de query welke ik hierboven gaf maar te injecten. Maak maar een voorbeeld scriptje, pleur 'm online en wij gaan met z'n allen proberen 'm te injecten. Safe genoeg voor huis tuin en keuken gebruik.
Je mist het punt. SQL injection hoeft niet altijd schadelijk te zijn, maar als jij nou een voorbeeld geeft waarbij injection mogelijk is en een gebruiker gaat dezelfde methode ook voor andere (mogeiljk gevaarlijkere) queries gebruiken, dan zijn de poppen aan het dansen. Beter gebruik je één uniforme methode om dit soort dingen af te handelen, dan de ene keer het wel te doen en de andere keer niet onder het mom van 'het werkt toch';
quote:
Ja met die intval is dat risico zeer zeker aanwezig inderdaad. Tenslotte verkomt dat op geen enkele manier dat er data uit de database getrokken kan worden welke niet voor de persoon bedoelt is
In dit geval was de intval() bedoeld om er zeker van te zijn dat het een numeriek type is wat in de query gezet wordt, op het moment dat je geen intval gebruikt en je staat toe dat er tekst in een gevaarlijke query komt gaat het wellicht nog erger fout. Ik ben het helemaal met je eens dat de user input gevalideerd moet worden, maar validatie is véél makkelijker als je weet met wat voor type variabele je te maken hebt - bovendien is bij een slechte validatie de kans op injection dan verkleind aangezien je zeker weet dat de user input in het type staat dat in de query mág staan.
pi_30181555
Ter info, de gewraakte query:

1
2
3		<?php
$query = 'SELECT * FROM `database` WHERE `id` = ' . $id;
?>
quote:
Op donderdag 1 september 2005 20:01 schreef Swetsenegger het volgende:
Ik heb het geprobeerd te injecten, en dat lukt echt niet zolang je je data in je query maar tussen ' zet.
En gewoon is_numeric volstaat natuurlijk ook

want laten we het nu eens proberen te injecten
we maken '""DROP TABLE tabel" van de id= in de url.
wat krijgen we dan?
Dan krijg je inderdaad onzin.
Maar, als we in de id= waarde nou een ' verstoppen kun je daarachter leuke sql opnemen.
Een voorbeeldje, stel dat er nog een tabel `auth` is met plaintext usernames en passwords (of md5 hashes, daar kan een hacker ook wel wat mee). De volgende injectie moet dan toch best wat leuks kunnen laten zien (mits mysql versie 4 of hoger gebruikt)

1
2
3
4
5
6
7		<?php
# stel $_GET[...] = "0 UNION SELECT * FROM `auth`"
$id = $_GET[...];
$query = 'SELECT * FROM `database` WHERE `id` = ' . $id;

# $query is nu: "SELECT * FROM `database` WHERE `id` = 0 UNION SELECT * FROM `auth`"
?>


Wauw! Geldige query die mysql zonder problemen uitvoert. Fijn, we krijgen nu als resultaat naast het bedoelde antwoord ook 1 of meerdere regels uit de auth tabel.
Eventueel in plaats van een * kolomnamen hernoemen zodat ze meegenomen worden naar de juiste uitvoer van de pagina, maar daar is wel wat op te vinden.

edit: kleine toevoeging: de oplossing om de $_GET variabele door intval heen te halen zal deze methode van sql injection zeker tegenhouden, er staat namelijk alles behalve alleen een integer in.
Ieder verhaal eindigt gelukkig, als je er maar vroeg genoeg mee stopt. - Annie M.G. Schmidt -
  FOK!-Schrikkelbaas donderdag 1 september 2005 @ 22:10:58 #36
1972 Swetsenegger
Egocentrische Narcist
pi_30181645
quote:
Op donderdag 1 september 2005 22:01 schreef JeRa het volgende:
In dit geval was de intval() bedoeld om er zeker van te zijn dat het een numeriek type is wat in de query gezet wordt, op het moment dat je geen intval gebruikt en je staat toe dat er tekst in een gevaarlijke query komt gaat het wellicht nog erger fout. Ik ben het helemaal met je eens dat de user input gevalideerd moet worden, maar validatie is véél makkelijker als je weet met wat voor type variabele je te maken hebt - bovendien is bij een slechte validatie de kans op injection dan verkleind aangezien je zeker weet dat de user input in het type staat dat in de query mág staan.
practise what you preach
quote:
Mijn opvatting is dat als het op een andere, betere manier kan, je als scripter die er wat meer verstand van heeft de morele verplichting hebt die zo goed mogelijk te melden
Kortom, je antwoord was net zo onveilig en onvolledig dan dat van mij. Sterker nog, jij bracht het nog als 'veilig'. En in MIJN opinie is geen veiligheid nog altijd beter dan schijn veiligheid.

Bottomline, voor elke scripter, lees die link welke ik een paar posts hierboven hebt geplaatst.
 | FOK! Schrikkelbaasch
pi_30181825
quote:
Op donderdag 1 september 2005 22:10 schreef Swetsenegger het volgende:

Kortom, je antwoord was net zo onveilig en onvolledig dan dat van mij. Sterker nog, jij bracht het nog als 'veilig'. En in MIJN opinie is geen veiligheid nog altijd beter dan schijn veiligheid.
Waar bracht ik het als veilig? ik zei alleen dat het SQL injection voorkwam, en dat is veiliger, maar niet veilig. In de praktijk blijkt niets veilig, daar gaat geen artikel iets aan veranderen
  FOK!-Schrikkelbaas donderdag 1 september 2005 @ 22:18:26 #38
1972 Swetsenegger
Egocentrische Narcist
pi_30181893
quote:
Op donderdag 1 september 2005 22:08 schreef Vloris het volgende:
Ter info, de gewraakte query:
[ code verwijderd ]
Nee daar ga je de fout al in
DIT was de gewraakte query

1
2
3		<?php
$query="SELECT * FROM table WHERE id='".$_GET['id']."'";
?>
quote:
Dan krijg je inderdaad onzin.
Maar, als we in de id= waarde nou een ' verstoppen kun je daarachter leuke sql opnemen.
Een voorbeeldje, stel dat er nog een tabel `auth` is met plaintext usernames en passwords (of md5 hashes, daar kan een hacker ook wel wat mee). De volgende injectie moet dan toch best wat leuks kunnen laten zien (mits mysql versie 4 of hoger gebruikt)
Nee hoor, dan krijgen we dit

1
2
3		<?php
$query="SELECT * FROM table WHERE id='"0 UNION SELECT * FROM `auth`"'";
?>

Dat doet niets behalve een query fout genereren.
quote:
Wauw! Geldige query die mysql zonder problemen uitvoert. Fijn, we krijgen nu als resultaat naast het bedoelde antwoord ook 1 of meerdere regels uit de auth tabel.
Eventueel in plaats van een * kolomnamen hernoemen zodat ze meegenomen worden naar de juiste uitvoer van de pagina, maar daar is wel wat op te vinden.
En dan ga je er al vanuit dat de hacker allerlei kennis heeft over je database model.

Ja de intval zal inderdaad in dit geval een fout geven, maar als de gebruiker idtje 5 in 6 veranderd trekt hij gewoon de info uit de tabel.

Het antwoord van Jera was dus niets vollediger dan dat van mij, terwijl hij dat wel suggereerde.
 | FOK! Schrikkelbaasch
pi_30182096
quote:
Op donderdag 1 september 2005 22:18 schreef Swetsenegger het volgende:

[..]

Het antwoord van JeRa was dus niets vollediger dan dat van mij, terwijl hij dat wel suggereerde.
Je bericht is een kwartier naderhand gewijzigd, dat zag ik ook niet. Maar 'id' is vast een numeriek type, en die ga je vergelijken met een string? bovendien voorkomt intval de invoeging van tekst in een query, want jouw methode voorkomt ook niet dat iemand andere info uit de database haalt. Ik zei alleen dat dat met SQL injection wellicht mogelijk was, maar in de oorspronkelijke query moet daar natuurlijk validatie aan vooraf gaan
pi_30182580
Goed, even snel.
Swetsenegger: dan pak ik die query met quotes en zorg ik ervoor dat $_GET['id'] begint met 0' UNION ... etc.
Misschien moet er nog een \ voor de ', dat zou kunnen, maar die is er prima in te futselen. En het probleem dat er ineens nog een ' achteraan komt is eenvoudig op te lossen door mijn injectie te laten eindigen op een nutteloze WHERE 'foo' = 'foo
(misschien ook weer \' dat weet ik zo niet precies)
Ieder verhaal eindigt gelukkig, als je er maar vroeg genoeg mee stopt. - Annie M.G. Schmidt -
pi_30182940
quote:
Op donderdag 1 september 2005 22:18 schreef Swetsenegger het volgende:

Nee hoor, dan krijgen we dit
[ code verwijderd ]
Waar komen die dubbele quotes opeens vandaan? Die zijn er niet, en dan krijg je het probleem dat Vloris hierboven opmerkt en waarvoor ik mij schaam dat ik dat niet eerder zag nu kun je wel die string gaan escapen, maar het is een numeriek type waardoor het allemaal zo gigantisch overdone is. In een query behoor je kolommen te vergelijken met waardes in hetzelfde type, dus INTs met integers en CHARs met strings. Zodra je dit door elkaar gaat halen kun je er vanuit gaan dat het een keer mis gaat (zoals nu).
  FOK!-Schrikkelbaas donderdag 1 september 2005 @ 22:56:32 #42
1972 Swetsenegger
Egocentrische Narcist
pi_30183445
quote:
Op donderdag 1 september 2005 22:23 schreef JeRa het volgende:

[..]

Je bericht is een kwartier naderhand gewijzigd, dat zag ik ook niet.
Het enige wat ik er aan toegevoegd heb is de ; De rest is echt niet gewijzigs
quote:
Maar 'id' is vast een numeriek type, en die ga je vergelijken met een string?
quote:
bovendien voorkomt intval de invoeging van tekst in een query,
is_numeric ook.
quote:
want jouw methode voorkomt ook niet dat iemand andere info uit de database haalt. Ik zei alleen dat dat met SQL injection wellicht mogelijk was, maar in de oorspronkelijke query moet daar natuurlijk validatie aan vooraf gaan
wanneer je je data tussen ' ' zet is injection niet zo eenvoudig als het lijkt.
 | FOK! Schrikkelbaasch
  FOK!-Schrikkelbaas donderdag 1 september 2005 @ 22:58:22 #43
1972 Swetsenegger
Egocentrische Narcist
pi_30183526
quote:
Op donderdag 1 september 2005 22:43 schreef JeRa het volgende:

[..]

Waar komen die dubbele quotes opeens vandaan?
Die staan er al vanaf de eerste post van mij hierover
quote:
Op donderdag 1 september 2005 19:52 schreef Swetsenegger het volgende:

$query=" SELECT * FROM database WHERE id='".$_GET['id']";
Hij staat niet tussen php tags, dus het is lastig te zien
 | FOK! Schrikkelbaasch
  FOK!-Schrikkelbaas donderdag 1 september 2005 @ 22:59:25 #44
1972 Swetsenegger
Egocentrische Narcist
pi_30183578
quote:
Op donderdag 1 september 2005 22:34 schreef Vloris het volgende:
Goed, even snel.
Swetsenegger: dan pak ik die query met quotes en zorg ik ervoor dat $_GET['id'] begint met 0' UNION ... etc.
Misschien moet er nog een \ voor de ', dat zou kunnen, maar die is er prima in te futselen. En het probleem dat er ineens nog een ' achteraan komt is eenvoudig op te lossen door mijn injectie te laten eindigen op een nutteloze WHERE 'foo' = 'foo
(misschien ook weer \' dat weet ik zo niet precies)
Be my guest, zet een voorbeeld scriptje in elkaar en probeer het.

Het enige wat je krijgt is sql errors. En dan hebben we het nog niet eens over het feit dat je blijkbaar verregaande kennis hebt van het database model.
 | FOK! Schrikkelbaasch
pi_30183631
quote:
Op donderdag 1 september 2005 22:56 schreef Swetsenegger het volgende:


is_numeric ook.
is_numeric controleert of het in het goede type staat. intval() zet het automatisch om naar het goede type. alleen zie ik is_numeric niet echt staan bij die query, en het zorgt er niet voor dat de waarde ook automatisch is wat je wilde. Met intval is het zelfs mogelijk om '3 schapen' in te voeren en daar het goede getal uit te krijgen.

En 'id' is meestal een kolom van het type UNSIGNED INT, en een integer moet je vergelijken met een integer en niét met een string (wat je in die query nu dus in feite doet).
quote:
[..]

wanneer je je data tussen ' ' zet is injection niet zo eenvoudig als het lijkt.
Een \' om de quotes te omzeilen is meer dan genoeg.
pi_30183633
quote:
Op donderdag 1 september 2005 22:56 schreef Swetsenegger het volgende:
wanneer je je data tussen ' ' zet is injection niet zo eenvoudig als het lijkt.
Kijk, dat bedoelde ik in m'n vorige post ook, misschien is dit dan ten overvloede, maar je kunt best ' tekentjes injecten. Dat probeerde ik eigenlijk aan te tonen. Zonder voorzorgsmaatregelen (als b.v. magic_quotes ergens enigszins aan staat) is het dan prima te injecten.
Ieder verhaal eindigt gelukkig, als je er maar vroeg genoeg mee stopt. - Annie M.G. Schmidt -
pi_30183687
quote:
Op donderdag 1 september 2005 22:58 schreef Swetsenegger het volgende:

[..]

Die staan er al vanaf de eerste post van mij hierover
[..]

Hij staat niet tussen php tags, dus het is lastig te zien
Dit schreef jij:
$query="SELECT * FROM table WHERE id='"0 UNION SELECT * FROM `auth`"'";
Die code die jij beschrijft zorgt echt niet voor de aanhalingstekens, hoogstens voor de enkele quotes ('). Het resultaat dat geproduceerd wordt is dus zonder de aanhalingstekens, maar met de enkele quotes. Als de user iets doet in de trant van:

' OR 1 OR '

Dan heb je dat dus al omzeild.
pi_30183848
quote:
Op donderdag 1 september 2005 22:59 schreef Swetsenegger het volgende:

[..]

Het enige wat je krijgt is sql errors. En dan hebben we het nog niet eens over het feit dat je blijkbaar verregaande kennis hebt van het database model.
Jij neemt kennelijk aan dat magic_quotes_gpc op On staat. Dit is echter niet altijd het geval. Als die niet aan staat is het ongelofelijk makkelijk om met quotes te spelen en géén error te laten optreden. En die verregaande kennis over het model, je hoeft alleen wat namen te kennen; en security through obscurity werkt natuurlijk niet he in principe zou een site zijn databaseopzet best bekend mogen maken als de site goed in elkaar steekt
  FOK!-Schrikkelbaas donderdag 1 september 2005 @ 23:07:54 #49
1972 Swetsenegger
Egocentrische Narcist
pi_30183880
quote:
Op donderdag 1 september 2005 23:00 schreef JeRa het volgende:

[..]

is_numeric controleert of het in het goede type staat. intval() zet het automatisch om naar het goede type.
Als ik iets niet wil in mijn query is het ongecontroleerd 'automatische' scriptjes
quote:
alleen zie ik is_numeric niet echt staan bij die query,
Nee, en bij jouw query zie ik ook geen controle op user input staan.
JIJ begon dit lul verhaal met te suggereren dat je query zoveel veiliger voor injection was dan de mijn door je intval toevoeging. Door het ontbreken van quotes echter, is de boel eerder onveiliger. MIjn reactie gaat er dus ook over dat je zogezegd de 'morele' verplichting voelt verbeteringen aan te brengen welke geen verbeteringen zijn. Had je het gewoon gebracht van 'denk om veiligheid' had ik je volmondig gelijk gegeven, maar op een pedant toontje een verbetering siggereren welke dat niet is kan ik slecht tegen.
quote:
en het zorgt er niet voor dat de waarde ook automatisch is wat je wilde.
Nee, het zorgt dat het TYPE automatisch is wat ik wilde. Of de waarde klopt heb ik geen enkel idee van.
quote:
Met intval is het zelfs mogelijk om '3 schapen' in te voeren en daar het goede getal uit te krijgen.
Dat geeft '0'. -edit- nopes, 3. Nu maar hopen dat je 3 wilde hebben
quote:
En 'id' is meestal een kolom van het type UNSIGNED INT, en een integer moet je vergelijken met een integer en niét met een string (wat je in die query nu dus in feite doet).
$_GET['id'] is geen string, maar een variable, met in dit geval een integer en geen string.
quote:
Een \' om de quotes te omzeilen is meer dan genoeg.
Nogmaals, be my guest. Maak een voorbeeld scriptje en ga lekker de hele avond zitten injecten. Ik zie je voorbeeld injection graag tegemoed.

[ Bericht 5% gewijzigd door Swetsenegger op 01-09-2005 23:14:41 ]
 | FOK! Schrikkelbaasch
  FOK!-Schrikkelbaas donderdag 1 september 2005 @ 23:10:00 #50
1972 Swetsenegger
Egocentrische Narcist
pi_30183962
quote:
Op donderdag 1 september 2005 23:02 schreef JeRa het volgende:

[..]

Dit schreef jij:
$query="SELECT * FROM table WHERE id='"0 UNION SELECT * FROM `auth`"'";
Die code die jij beschrijft zorgt echt niet voor de aanhalingstekens, hoogstens voor de enkele quotes ('). Het resultaat dat geproduceerd wordt is dus zonder de aanhalingstekens, maar met de enkele quotes. Als de user iets doet in de trant van:

' OR 1 OR '

Dan heb je dat dus al omzeild.


1
2
3		<?php
$query="SELECT * FROM table WHERE iets='".$variabele."'";
?>

Vul de injection van Vloris maar in bij $variable... en wat zien we dan? tadaaaaa quotes.

1
2
3		<?php
$query="SELECT * FROM table WHERE iets='"SELECT * FROM `database` WHERE `id` = 0 UNION SELECT * FROM `auth`"'";
?>
 | FOK! Schrikkelbaasch
pi_30184032
Pak nou eens dit:

' OR 1 OR ''='

Wat krijg je dan? Juist:

SELECT * FROM table WHERE iets='' OR 1 OR ''=''
pi_30184078
quote:
Op donderdag 1 september 2005 23:07 schreef Swetsenegger het volgende:
$_GET['id'] is geen string, maar een variable, met in dit geval een integer en geen string.
Snap nou eens dat als je $_GET['id'] tussen quotes zet in een query, je er dan een string van maakt je query gaat dan vervolgens de kolom 'id' vergelijken met een string.
pi_30184141
quote:
Op donderdag 1 september 2005 23:07 schreef Swetsenegger het volgende:
Door het ontbreken van quotes echter, is de boel eerder onveiliger.
Door de intval() toevoeging weet je zeker dat de waarde een getal is en zijn quotes niet meer nodig! Quotes zijn niet heilig! bovendien kun je in de rest van je script werken met een waarde die je ook in je query hebt meegegeven
  FOK!-Schrikkelbaas donderdag 1 september 2005 @ 23:17:25 #54
1972 Swetsenegger
Egocentrische Narcist
pi_30184244
quote:
Op donderdag 1 september 2005 23:11 schreef JeRa het volgende:
Pak nou eens dit:

' OR 1 OR ''='

Wat krijg je dan? Juist:

SELECT * FROM table WHERE iets='' OR 1 OR ''=''
1
2
3		<?php
$query="SELECT * FROM table WHERE iets='' OR 1 OR ''=''";
?>

Prachtige sql fout

-edit- hmmmmmzzzz...
 | FOK! Schrikkelbaasch
  FOK!-Schrikkelbaas donderdag 1 september 2005 @ 23:17:45 #55
1972 Swetsenegger
Egocentrische Narcist
pi_30184258
quote:
Op donderdag 1 september 2005 23:13 schreef JeRa het volgende:

[..]

Snap nou eens dat als je $_GET['id'] tussen quotes zet in een query, je er dan een string van maakt je query gaat dan vervolgens de kolom 'id' vergelijken met een string.
en je voorkomt injection
 | FOK! Schrikkelbaasch
  FOK!-Schrikkelbaas donderdag 1 september 2005 @ 23:18:20 #56
1972 Swetsenegger
Egocentrische Narcist
pi_30184279
quote:
Op donderdag 1 september 2005 23:14 schreef JeRa het volgende:

[..]

Door de intval() toevoeging weet je zeker dat de waarde een getal is en zijn quotes niet meer nodig! Quotes zijn niet heilig! bovendien kun je in de rest van je script werken met een waarde die je ook in je query hebt meegegeven
Waarom kan ik dat niet in de rest van mijn script? $_GET['id'] veranderd niet opeens magisch
 | FOK! Schrikkelbaasch
pi_30184344
quote:
Op donderdag 1 september 2005 23:17 schreef Swetsenegger het volgende:

[..]
[ code verwijderd ]

Prachtige sql fout
Heb je 'm uitgeprobeerd? Hier werkt die query gewoon hoor...
pi_30184398
Oke, we hebben:

1
2
3		<?php
$query="SELECT * FROM table WHERE iets='".$_GET['id']."'";
?>


We hebben een url: http://example.com/foobar(...)WHERE+'foo'+%3D+'foo

(%60 is ` en %3D is = en + is een spatie, zie b.v. hier voor een encode / decode scriptje )
Wat krijgen we vervolgens in $query?

1
2
3		<?php
$query == "SELECT * FROM table WHERE iets='0' UNION SELECT * FROM `auth` WHERE 'foo' = 'foo'";
?>


De enige maar die hier aan hangt is het eventueel aan staan van de magic_quotes settings waarbij php bij alle $_GET variabelen ' vervangt door \'
In dat geval werkt het niet helemaal zo.

Blijft inderdaad overeind dat je een heel eind moet gokken naar de database structuur, dat is waar. Maar vaak hebben dat soort tabellen hele logische namen.
Ieder verhaal eindigt gelukkig, als je er maar vroeg genoeg mee stopt. - Annie M.G. Schmidt -
pi_30184415
quote:
Op donderdag 1 september 2005 23:17 schreef Swetsenegger het volgende:

[..]

en je voorkomt injection
Doe dat dan op een andere manier, je voorkomt zo alleen injection als je magic_quotes_gpc op On hebt staan maar op jouw methode moet er vanalles gecast gaan worden door MySQL alvorens die kan gaan checken. Dit is gewoon überfout:

SELECT * FROM table WHERE 1 = '1'

Maar dat is feitelijk wat je nu doet
pi_30184462
quote:
Op donderdag 1 september 2005 23:22 schreef JeRa het volgende:
Dit is gewoon überfout:

SELECT * FROM table WHERE 1 = '1'

Maar dat is feitelijk wat je nu doet
Een 'echte' sql server zou het niet eens goedkeuren als je een numerieke kolom vergelijkt met een string... Maar mysql reken ik dan even niet tot de echten.
Ieder verhaal eindigt gelukkig, als je er maar vroeg genoeg mee stopt. - Annie M.G. Schmidt -
  FOK!-Schrikkelbaas donderdag 1 september 2005 @ 23:25:17 #61
1972 Swetsenegger
Egocentrische Narcist
pi_30184520
quote:
Op donderdag 1 september 2005 23:20 schreef JeRa het volgende:

[..]

Heb je 'm uitgeprobeerd? Hier werkt die query gewoon hoor...
Zag je mijn edit?
Ja hij werkt.

Maar goed, zowel jouw als mijn antwoord was onvolledig.
Dus hierbij voor de volledigheid voor de originele vraagsteller....

ALTIJD je user input controleren.
 | FOK! Schrikkelbaasch
pi_30184533
quote:
Op donderdag 1 september 2005 23:23 schreef Vloris het volgende:

[..]

Een 'echte' sql server zou het niet eens goedkeuren als je een numerieke kolom vergelijkt met een string... Maar mysql reken ik dan even niet tot de echten.
Daarom is het eigenlijk ook volstrekt hilarisch dat PHP & MySQL de meest gebruikte combinatie is...ze laten allebei enorm veel fouten toe m.b.t. types waardoor een hoop mensen het verkeerd gaan doen
  FOK!-Schrikkelbaas donderdag 1 september 2005 @ 23:27:15 #63
1972 Swetsenegger
Egocentrische Narcist
pi_30184609
quote:
Op donderdag 1 september 2005 23:22 schreef JeRa het volgende:

[..]

Doe dat dan op een andere manier, je voorkomt zo alleen injection als je magic_quotes_gpc op On hebt staan maar op jouw methode moet er vanalles gecast gaan worden door MySQL alvorens die kan gaan checken. Dit is gewoon überfout:

SELECT * FROM table WHERE 1 = '1'

Maar dat is feitelijk wat je nu doet
Een beetje server heeft magic_quotes_gpc gewoon aan staan.
En leeg eens uit waarom dat uberfout zou zijn?

'gewoon' is wel erg magere uitleg.
 | FOK! Schrikkelbaasch
pi_30184651
quote:
Op donderdag 1 september 2005 23:25 schreef JeRa het volgende:
Daarom is het eigenlijk ook volstrekt hilarisch dat PHP & MySQL de meest gebruikte combinatie is...ze laten allebei enorm veel fouten toe m.b.t. types waardoor een hoop mensen het verkeerd gaan doen
Dat ben ik helemaal met je eens. En wat mij betreft laten we het hierbij, het was absoluut niet mijn bedoeling jou bewering helemaal onderuit te halen, ik wou alleen maar aantonen hoe het eventueel misbruikt zou kunnen worden.

Ondertussen zijn er ook al een aantal goeie oplossingen gevonden.

Ik ga weer verder met postgres (en de PEAR::DB package, die snapt tenminste transactions) icm php.
Ieder verhaal eindigt gelukkig, als je er maar vroeg genoeg mee stopt. - Annie M.G. Schmidt -
pi_30184683
quote:
Op donderdag 1 september 2005 23:25 schreef Swetsenegger het volgende:

[..]

Zag je mijn edit?
Aan mijn post te zien, niet
quote:
Ja hij werkt.

Maar goed, zowel jouw als mijn antwoord was onvolledig.
Dus hierbij voor de volledigheid voor de originele vraagsteller....

ALTIJD je user input controleren.
En voor de volledigheid van mijn kant geef ik ook even aan wat ik bedoelde met het type dat je kunt gebruiken in de rest van je script:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16		<?php
//User input ophalen en omzetten naar het gewenste type
$id = intval($_GET['id']);
$naam = trim($_GET['naam']);

//Validatie
if ($id &lt;= 0) {
    ...fout!
}
if ($naam == '') {
    ...fout!
}

//Afhandeling in script kan nu gedaan worden met $id en $naam, die zowel gevalideerd zijn als in het goede type zijn gezet, en pas in de query ge-escaped worden (indien nodig)
$query = 'SELECT * FROM `blaat` WHERE `id` = ' . $id . ' AND `naam` = \'' . mysql_real_escape_string($naam) . '\'';
?>


edit: dit gaat er trouwens vanuit dat magic_quotes_gpc uit staat, wat ik doe is controleren of magic_quotes_gpc aan staat en indien dit zo is alle request variabelen strippen van hun slashes

[ Bericht 3% gewijzigd door JeRa op 01-09-2005 23:42:53 ]
pi_30184816
quote:
Op donderdag 1 september 2005 23:27 schreef Swetsenegger het volgende:

[..]

Een beetje server heeft magic_quotes_gpc gewoon aan staan.
En leeg eens uit waarom dat uberfout zou zijn?

'gewoon' is wel erg magere uitleg.
Een beetje server heeft dat inderdaad, maar een hoop servers hebben dat niet. In mijn scripts heb ik altijd helemaal vooraan een stukje code die alle input omzet naarmate magic_quotes_gpc aan of uit staat.

Dat is überfout omdat 1 een getal is en '1' een string is. Als je een kolom van type UNSIGNED INT hebt, en je deze met een string gaat vergelijken, zou een goede DB een foutmelding produceren zoals Vloris al zei. Dat MySQL dat toestaat is tot daaraan toe, maar het hoort niet en MySQL moet zo eerst de string naar een INT casten voordat het er iets mee kan.
pi_30185615
Ik wil graag alles wat met een a begint uit een mysql db kunnen selecteren maar ik heb geeb flauw idee wat voor myswl qeury ik moet maken dan. Iemand een idee (kan het ook niet vinden op mysql.com)
pi_30186156
Even een voorbeeld; als je een tabel hebt met een id (unieke waarde) en een kolom waar je op wilt selecteren, dan kun je zoiets doen:

SELECT `id` FROM `table` WHERE `kolom` LIKE 'a%'

Het procentteken is in een LIKE-clause een wildcard, het resultaat van deze query komt dus overeen met alle IDs van de records waarvan die kolom met een a begint (en wat daarna komt maakt niet uit).
pi_30186305
Ach wat ben ik dom!
Dat had ik zelf kunnen bedenken!
  vrijdag 2 september 2005 @ 02:24:13 #70
71919 wonderer
Hung like a My Little Pony
pi_30189385
Ik heb duidelijk op het verkeerde moment mijn probleem gepost
"Pain is my friend. I can trust pain. I can trust pain to make my life utterly miserable."
"My brain is too smart for me."
"We don't need no education." "Yes you do, you just used a double negative."
pi_30191996
quote:
Op donderdag 1 september 2005 23:27 schreef Swetsenegger het volgende:

[..]

Een beetje server heeft magic_quotes_gpc gewoon aan staan.
En leeg eens uit waarom dat uberfout zou zijn?

'gewoon' is wel erg magere uitleg.
O wat haat ik die "feature" van php. Het slaat echt helemaal nergens op om alle binnenkomende get/post/cookie data te voorzien van slashes omdat het misschien in een sql statement gebruikt gaat worden. Je hebt er alleen maar last van als je iets anders met de data wil doen; een preview van een post, validatie van een string op lengte, of gewoon elk willekeurige actie die niets met mysql te maken heeft.

Overigens staat in php.ini-recommended magic_quotes_gpc = off.
Een beetje server heeft magic_quotes_gpc dus uit staan.
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
pi_30192842
quote:
Op vrijdag 2 september 2005 07:34 schreef SuperRembo het volgende:
Overigens staat in php.ini-recommended magic_quotes_gpc = off.
Een beetje server heeft magic_quotes_gpc dus uit staan.
Ze geven twee redenen in php.ini voor de keuze om magic_quotes_gpc standaard op Off te zetten. De ene is performance (PHP hoeft dan niet langer alle request variabelen te voorzien van slashes) en de tweede is het feit dat je dan zogenaamd alles direct in database kunt stoppen, alleen moet je volgens PHP dan wel addslashes() gebruiken die opmerking vind ik dan weer wat vreemd.

Niet alleen omdat je dan dus niét zomaar alles in een table kunt stoppen, maar ook omdat addslashes() geen rekening houdt met de character set van de database, wat nog wel eens het geval kan zijn bij de latere versies van bv. MySQL. De eigenlijke functies die bedoeld zijn om data te escapen die in een query moet, zijn: mysql_real_escape_string(), mysqli_real_escape_string() en pg_escape_string(). Deze functies worden boven addslashes() geprefereerd, al is het alleen maar omdat er misschien verschil komt in de manier van escapen of omdat er een character set gewijzigd wordt.
pi_30252388
Overigens is het handig om al je input te zuiveren van dit magic_quotes gedoe (met behulp van strip_slashes), en dan zélf bewust, bijvoorbeeld in een Database Access Layer, netjes te escapen / te validaten .

[edit]Idd in het geval van de onmogelijkheid tot het gebruik van het aanpassen van de config, of dat nu in de file of via .htaccess is

[ Bericht 21% gewijzigd door idontlikepizza op 04-09-2005 13:07:39 (Geen reden tot een nieuwe post :)) ]
The Noodle Theorem
pi_30255103
quote:
Op zondag 4 september 2005 10:27 schreef idontlikepizza het volgende:
Overigens is het handig om al je input te zuiveren van dit magic_quotes gedoe (met behulp van strip_slashes), en dan zélf bewust, bijvoorbeeld in een Database Access Layer, netjes te escapen / te validaten .
Als je zelf de server config niet kan wijzigen, dan kan je 't uitschakelen met een regeltje in een .htaccess file:

1php_flag magic_quotes_gpc off
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
  zondag 4 september 2005 @ 15:00:06 #75
71610 Black-Hole
Deep in my soul
pi_30258667
Via phpmyadmin heb ik 1 van mijn databases geexporteerd. Nu is het geexporteerde bestand 7,51mb groot terwijl de database in phpmyadmin 10,7mb groot is.

Het geexporteerde bestand is niet gecomprimeerd maar toch zit er een verschil in

Klopt dat of die ik iets fout? De geexporteerde database is die van mijn forum (Invision PowerBoard), misschien geef ik zo nog net iets meer info.

Edit: screendump van hoe ik het gedaan heb:

pi_30259457
Het ene opslagformaat kan toch ook gewoon efficiënter zijn? . En als je het wil testen importeer je de zut toch?
The Noodle Theorem
  zondag 4 september 2005 @ 15:35:26 #77
71610 Black-Hole
Deep in my soul
pi_30259569
quote:
Op zondag 4 september 2005 15:30 schreef idontlikepizza het volgende:
Het ene opslagformaat kan toch ook gewoon efficiënter zijn? . En als je het wil testen importeer je de zut toch?
Zou goed kunnen hoor, ik doe het ook maar voor het eerst

Kan je aan de bijgevoegde pic zien of ik het goed gedaan heb of moet ik hem dan echt weer importeren?
pi_30259620
Volgens mij wel. Maar het importeren in een test-database kost niet echt veel moeite, lijkt me? Zeker met die grootte..
The Noodle Theorem
  zondag 4 september 2005 @ 20:42:30 #79
71610 Black-Hole
Deep in my soul
pi_30269017
quote:
Op zondag 4 september 2005 15:38 schreef idontlikepizza het volgende:
Volgens mij wel. Maar het importeren in een test-database kost niet echt veel moeite, lijkt me? Zeker met die grootte..
Het is allemaal gelukt, wel mat wat knip- en plakwerk omdat de file groter was dan 1,5mb.
pi_30275410
Ik weet niet hoe je je databasegrootte hebt bepaald, maar als je de tabellen gaat exporteren is dit altijd zonder de indices. Deze worden namelijk weer aangemaakt zodra je de boel importeert
pi_30317400
Ja collega´s en mede fokkers.
Even geen zin om nieuw topic te openen.

Maar ik ben ok zoek naar een mooie portal voor mijn website.
Ik heb op dit moment Mambo maar veel menesen vertellen me dat die te zwaar is en niet helemaal ideaal.
Kan iemand me helpen met wat tips?

Tnx
pi_30323223
Waarom wil je eigenlijk van mambo af? Heb je er problemen mee of draait je machine niet lekker?
quote:
Op dinsdag 6 september 2005 13:06 schreef Godlike02 het volgende:
Ik heb op dit moment Mambo maar veel menesen vertellen me dat die te zwaar is en niet helemaal ideaal.
is een beetje ala "ik wil een andere auto want volgens mijn buurman is mijn huidige niet goed".
pi_30323733
quote:
Op dinsdag 6 september 2005 16:01 schreef devzero het volgende:
Waarom wil je eigenlijk van mambo af? Heb je er problemen mee of draait je machine niet lekker?
[..]

is een beetje ala "ik wil een andere auto want volgens mijn buurman is mijn huidige niet goed".
Draaid prima.
Maar ik wil verder kijken.

Ik vind de interface niet helemala ideaal.
Dus orientatie
pi_30325022
Dat hoort imho in een apart topic, aangezien jouw vraag helemaal niet over PHP of MySQL gaat en geen zin om een nieuw topic te openen, het enige wat je extra moet doen is een titel verzinnen
  FOK!-Schrikkelbaas dinsdag 6 september 2005 @ 21:49:00 #85
1972 Swetsenegger
Egocentrische Narcist
pi_30334717
Heren, ik heb een preg_match nodig, welke controleert of een invoer uit minimaal 9 en maximaal 10 decimale getallen bestaat. MAAR als het 9 decimale getallen betreft moet de tiende de letter x zijn....

preg_match("/^[0-9]{9,10}$/i"

Ok, maar hoe plak ik die x erin?

-edit-
preg_match("/^[0-9]{10}|^[0-9]{9}x{1}$/i"

[ Bericht 10% gewijzigd door Swetsenegger op 06-09-2005 22:06:54 ]
 | FOK! Schrikkelbaasch
pi_30335215
/^[0-9]{9,9}[0-9x]$/i
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
  FOK!-Schrikkelbaas dinsdag 6 september 2005 @ 22:09:25 #87
1972 Swetsenegger
Egocentrische Narcist
pi_30335494
quote:
Op dinsdag 6 september 2005 22:02 schreef SuperRembo het volgende:
/^[0-9]{9,9}[0-9x]$/i

Waarom zijn jouw reg_exps altijd mooier dan die van mij


 | FOK! Schrikkelbaasch
pi_30336167
Regexps zijn stoer
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
  FOK!-Schrikkelbaas dinsdag 6 september 2005 @ 22:28:06 #89
1972 Swetsenegger
Egocentrische Narcist
pi_30336194
quote:
Op dinsdag 6 september 2005 22:27 schreef SuperRembo het volgende:
Regexps zijn stoer
Dat kan ik alleen maar beamen (en verekte handig)
 | FOK! Schrikkelbaasch
pi_30340950
quote:
Op dinsdag 6 september 2005 22:27 schreef SuperRembo het volgende:
Regexps zijn stoer
Absoluut helemaal mee eens
fokstok.nl
pi_30357357
Helaas wordt preg_replace vaak te overijverig gebruikt. Zoiets als

$tekst = preg_replace('/blaat/', 'taalb', $tekst);

is iets wat veel mensen gebruiken om een stuk tekst te vervangen, terwijl

$tekst = str_replace('blaat', 'taalb', $tekst);

toch vele malen sneller is
  FOK!-Schrikkelbaas woensdag 7 september 2005 @ 16:53:07 #92
1972 Swetsenegger
Egocentrische Narcist
pi_30357878
quote:
Op woensdag 7 september 2005 16:37 schreef JeRa het volgende:
Helaas wordt preg_replace vaak te overijverig gebruikt. Zoiets als

$tekst = preg_replace('/blaat/', 'taalb', $tekst);

is iets wat veel mensen gebruiken om een stuk tekst te vervangen, terwijl

$tekst = str_replace('blaat', 'taalb', $tekst);

toch vele malen sneller is
Ja, dat zie ik ook vaak. of een check op e-mail adres met alleen @. Gebruik dan strstr...
 | FOK! Schrikkelbaasch
  woensdag 7 september 2005 @ 17:57:58 #93
52200 ViPeRII
It's a good day to die
pi_30360034
quote:
Op dinsdag 6 september 2005 22:27 schreef SuperRembo het volgende:
Regexps zijn stoer
Regexps zuigen als je niet goed weet hoe ze werken :S
Iemand nog eens een duidelijke "nederlandse" handleiding hiervoor?
-- ViPeRII --
pi_30360693
quote:
Op woensdag 7 september 2005 17:57 schreef ViPeRII het volgende:

[..]

Regexps zuigen als je niet goed weet hoe ze werken :S
Iemand nog eens een duidelijke "nederlandse" handleiding hiervoor?
Ik heb een powerpointpresentatie ooit eens via dit topic gekregen. Daar staat het best helder in (ik heb het nog niet zoveel gebruikt, dus ik weet niet of het diep genoeg gaat voor wat lastigere regexps )

Hier staat ie
Vogelaars.nl
  FOK!-Schrikkelbaas woensdag 7 september 2005 @ 19:48:16 #95
1972 Swetsenegger
Egocentrische Narcist
pi_30363445
Nieuw topic ivm de veiligheids issues tegenwoordig.
Op een aantal mail scripts, ontving ik plotseling wat vreemde mailtjes, met diverse mailadressen en de termen cc en bcc in de body en daarnaast veel van dit:

1
2
3
4
5
6
7
8
9		This is a multi-part message in MIME format. 

--===============1077165900== 
Content-Type: text/plain; charset=\"us-ascii\" 
MIME-Version: 1.0 
Content-Transfer-Encoding: 7bit 

utnzpw 
--===============1077165900==-- 


Na wat gezocht te hebben, zag ik in het commentaar bij de mail() functie op php.net dat meer mensen daar recent last van hebben. Mail injection is hot.

Ik kwam ook het volgende artikel tegen: http://securephp.damonkohler.com/index.php/Email_Injection

Nu controlleer ik de userinput voor mail met een preg_match, en die valideert niet de injections welke op boven genoemde url als voorbeeld worden genoemd. Als ik het goed interpreteer, is alleen userinput welke in de headers terecht komen (mailto en from dus) gevoelig voor dit soort injection, en de body niet.

Is dit correct? In de body variabelen kunnen ze MIME types, boundry en content type injecteren wat ze willen, en zal toch niet resulteren in mails naar ontvangers welke je niet wil?
 | FOK! Schrikkelbaasch
pi_30363686
quote:
Op dinsdag 6 september 2005 13:06 schreef Godlike02 het volgende:
Ja collega´s en mede fokkers.
Even geen zin om nieuw topic te openen.

Maar ik ben ok zoek naar een mooie portal voor mijn website.
Ik heb op dit moment Mambo maar veel menesen vertellen me dat die te zwaar is en niet helemaal ideaal.
Kan iemand me helpen met wat tips?

Tnx
e107.org
If I could offer you only one tip for the future, sunscreen would be it.
The long term benefits of sunscreen have been proved by scientists.
Deviantart
pi_30366721
quote:
Op woensdag 7 september 2005 19:48 schreef Swetsenegger het volgende:
Is dit correct? In de body variabelen kunnen ze MIME types, boundry en content type injecteren wat ze willen, en zal toch niet resulteren in mails naar ontvangers welke je niet wil?
Voor zover ik weet wel, maar het wordt wellicht een probleem als ze de boundary makkelijk kunnen raden. Als ze die kunnen raden en in hun message zetten heb je het probleem dat ze vervolgens wél headers kunnen opgeven.

Ook moet je er dus op letten dat dingen als naam, e-mailadres, etc die in de mailheaders komen géén ongeldige tekens mogen bevatten zoals een enter, want dan kun je ook extra headers opgeven.
  FOK!-Schrikkelbaas woensdag 7 september 2005 @ 21:26:53 #98
1972 Swetsenegger
Egocentrische Narcist
pi_30367458
quote:
Op woensdag 7 september 2005 21:11 schreef JeRa het volgende:

[..]

Voor zover ik weet wel, maar het wordt wellicht een probleem als ze de boundary makkelijk kunnen raden. Als ze die kunnen raden en in hun message zetten heb je het probleem dat ze vervolgens wél headers kunnen opgeven.
Ik ben niet zo into mails.
Ik doe zelf niets met boundry., voorzover ik weet. Het is toch niet zo dat elke mail een boundry heeft?
quote:
Ook moet je er dus op letten dat dingen als naam, e-mailadres, etc die in de mailheaders komen géén ongeldige tekens mogen bevatten zoals een enter, want dan kun je ook extra headers opgeven.
Nee met preg_match check ik gewoon voor een geldig e-mail adres en daar horen enters niet in
 | FOK! Schrikkelbaasch
  woensdag 7 september 2005 @ 22:02:04 #99
71919 wonderer
Hung like a My Little Pony
pi_30369131
Ik wil graag backupbestanden van 200000 records terugzetten... hoe kan ik dat het beste doen? Uploaden via SQL gaat niet...
"Pain is my friend. I can trust pain. I can trust pain to make my life utterly miserable."
"My brain is too smart for me."
"We don't need no education." "Yes you do, you just used a double negative."
pi_30372934
quote:
Op woensdag 7 september 2005 21:26 schreef Swetsenegger het volgende:

[..]

Ik ben niet zo into mails.
Hoeft niet, zolang je maar op de headers blijft letten
quote:
Ik doe zelf niets met boundry., voorzover ik weet. Het is toch niet zo dat elke mail een boundry heeft?
[..]
Boundaries worden gebruikt om een multipart e-mail (HTML-email bijvoorbeeld) op te delen in verschillende segmenten met verschillende headers (mime-type etc). Aangezien alleen een unieke boundary aan kan geven dat er een nieuw stuk (mét nieuwe headers) begint, moet je ervoor zorgen dat die ook echt uniek zal zijn. Waarschijnlijk heeft het verder geen gevolgen voor mailinjectie, aangezien de headers daar niet meer van toepassing zijn op de ontvanger.
quote:
Nee met preg_match check ik gewoon voor een geldig e-mail adres en daar horen enters niet in
Dan zit je wrs al gebakken mailinjecties zijn op slechte input controles gebaseerd, zoals een naam of e-mailadres dat klakkeloos in de headers wordt gegooid van de te versturen e-mail.
pi_30373004
quote:
Op woensdag 7 september 2005 22:02 schreef wonderer het volgende:
Ik wil graag backupbestanden van 200000 records terugzetten... hoe kan ik dat het beste doen? Uploaden via SQL gaat niet...
Je doet dit waarschijnlijk via phpMyAdmin? Die heeft de beperking van HTTP file uploads, enkele MB's dus. Wat je kunt doen:

  • andere tools gebruiken die geen limiet hebben en direct contact kunnen maken met de MySQL server
  • je backupbestanden opsplitsen zodat de afzonderlijke delen kleiner zijn dan de maximale toegestane limiet om te uploaden
    • actieve topics nieuwe topics
    abonnement Unibet Coolblue Bitvavo
    [PHP/(My)SQL] voor dummies - Deel 12
    Index

    » digital corner

    Forum Opties
    Forumhop:
    Hop naar:
    (afkorting, bv 'KLB')