SQL injections mot dette scriptet?

[Infite]

<?php
session_start();

include_once"includes/db_connect.php";
if (strip_tags($_GET['logout']) == "yes"){
session_destroy();
}

if (strip_tags($_POST['username']) && strip_tags($_POST['password'])){
$username = addslashes(strip_tags($_POST['username']));
$password = addslashes(strip_tags($_POST['password']));

$ip = $REMOTE_ADDR;

///check INFO
$sql = mysql_query("SELECT * FROM users WHERE username='$username' AND password='$password' AND activated='1' LIMIT 1");


$login_check = mysql_num_rows($sql);
$inf = mysql_fetch_object($sql);
if ($login_check == "0"){
$message="You could not be logged in";
}elseif ($login_check != "0"){


if ($login_check > "0"){
if ($inf->status == "Dead"){
include_once"dead.php";
exit();

}
if ($inf->status == "Banned"){
$encoded=md5(strtolower($username));
header("Location: banned.php?banned=$username&encoded=$encoded");
exit();

}

session_register('username');
$_SESSION['username'] = $inf->username;

$timestamp = time()+60;
mysql_query("UPDATE users SET online='$timestamp' WHERE username='$username'");
mysql_query("UPDATE users SET l_ip='$ip' WHERE username='$username'");

header("Location: logged_in.php");
} else {
$message= "You could not be logged in.<br />";
}}

}
?>

 

Var noen som visket meg i øret at det ikke ville være noe vannskelig og kjøre sql injection mot dette scriptet, kan noen forklare hvorfor? og hint til forbedring, gjerne eksempel på hvordan dette scriptet kan bli angrepet.

Takk

[Mats Danielsen]

Anbefaler deg å bruke mysql_real_escape_string(); istedet for addslashes og strip_tags. Dette er for å gjøre løsningen raskest mulig.

Men dette er sikkert mot det jeg deffinerer som SQL injections, dvs. gjøre om funksjonaliteten til en spøring.

 

Kan du fortelle meg som sa dette? For han / hun virker ikke helt stabil ut.

 

Må også si god jobb, veldig ryddig og ikke noe dårlig kode her.

[itsmebth]

Ikke noe dårlig kode?

• Ikke noe vits i å ha strip_tags overalt. Den trenges bare vis du skal skrive ut infoen.
  
• Hvis ikke du har variabler inni dem vil ' være bittelitt raskere enn "
  
• "$ip = $REMOTE_ADDR;" bruker register_globals
  
• "if ($login_check == "0"){" burde være "if ($login_check == 0){" (Det samme gjelder de andre stedene du bruker "0")
  
• Det holder med else, ikke else if
  

[Ernie]

Det er ren «bullshit» at du er sårbar for SQL-injections. Hvis noen skulle mene det får du be de komme med eksempler (noe man alltid bør når man påpeker sårbarheter). Sannsynligvis er det vel noen som tror addslashes ikke gjør dataene trygt nok for MySQL, noe som er delvis feil. Ja, det kan pr. teori utføres SQL-injections som ville blitt fanget opp med mysql_real_escape_string, MEN det vil krevet at dataene kommer inn noe annet enn ISO-8859-1, UTF8 e.l. samtidig som du ikke bruker nevnte tegnsett på tilkoblingen mot MySQL. Mao. så lenge tilkoblingen bruker ISO-8859-1 eller UTF8 er det absolutt ingen forskjell siden PHP nærmest bygger på ISO-8859-1 og UTF8 er ASCII-kompatibel noe som gjør at den vil ufarliggjøre dataene helt korrekt. Det betyr alikevel ikke at man skal bruke addslashes for sikring av data til MySQL. mysql_real_escape_string bør i aller høyeste grad foretrekkes over addslashes (det ultimate vil dog være «prepared statements»), men det betyr ikke at man absolutt må redigere scriptene sine fordi man bruker addslashes.

 

Forøvrig, både mysql_real_escape_string og addslashes kan gjøre et script sårbart for SQL-injections. Riktignok ikke «vanlig» SQL-injections (type muligheter for å ødelegge tabeller), men mer i den rettning at ingen av de escaper wildcards (% og _) og det leder til at man kan utføre DoS-angrep.

[magikern]

anbefaler deg å ta en titt på 'prepared statements' og bind params.

 

fra http://php.net/pdo

Prepared statements and stored procedures

 

Many of the more mature databases support the concept of prepared statements. What are they? You can think of them as a kind of compiled template for the SQL that you want to run, that can be customized using variable parameters. Prepared statements offer two major benefits:

 

* The query only needs to be parsed (or prepared) once, but can be executed multiple times with the same or different parameters. When the query is prepared, the database will analyze, compile and optimize it's plan for executing the query. For complex queries this process can take up enough time that it will noticeably slow down your application if you need to repeat the same query many times with different parameters. By using a prepared statement you avoid repeating the analyze/compile/optimize cycle. In short, prepared statements use fewer resources and thus run faster.

* The parameters to prepared statements don't need to be quoted; the driver handles it for you. If your application exclusively uses prepared statements, you can be sure that no SQL injection will occur. (However, if you're still building up other parts of the query based on untrusted input, you're still at risk).

 

Prepared statements are so useful that they are the only feature that PDO will emulate for drivers that don't support them. This ensures that you will be able to use the same data access paradigm regardless of the capabilities of the database.

 

forøvrig:

 

<?php

$ip = $REMOTE_ADDR;

mysql_query("UPDATE users SET l_ip='$ip' WHERE username='$username'");
?>

her kan $REMOTE_ADDR skrives om til det meste

f.eks noe alla:

&27;&59;DELETE&20;*&20;FROM&20;users

 

ps: skrevet etter hukommelse fra ascii tabellen så akkurat den linja er nok ikke helt riktg, men en variasjon av den kan gi deg problemer. uansett er hovedpoenget her at du ikke vet om $REMOTE_ADDR faktisk er en session variabel eller kanskje cookie,get,post, og du vet heller ikke om den følger strukturen til en standard ip adresse.

 

derimot hvis du kjører med register_globals=off (som man ALLTID bør gjøre) så er variabelen tom, noe som heller ikke gir særlig mening i queryen din.

[loathsome]

"register_globals" er ut for lenge siden. Skal du hente IP-adressen, så finnes denne som REMOTE_ADDR i $_SERVER-arrayen.