Forum PHP.pl

@MatheW: Właśnie chodziło mi o to, żeby nie dopuścić do bazy danych zawartości $_POST['login']. Bezpieczne jest zhaszowane hasło

Racja, nie wpisałem ostatniej modyfikacji....

[PHP] pobierz, plaintext 
<?php
$sql='SELECT id,login FROM baza WHERE haslo="'.md5($_POST['haslo']).'"';
$wynik=mysql_query($sql);
if (mysql_num_rows($wynik)>=1){
  $ok=true;
  while (($dana=mysql_fetch_row($wynik))&&($ok==true)){
	if ($dana[1]==$_POST['login'])){
	  //Zalogowany
	  $ok=false;
	  $_Session['id']=$wynik[0];
	  //Dalsze czynności....
	}
  }
}else{
  //złe hasło
}
?>
[PHP] pobierz, plaintext 

Hasła mogą być takie same, ale różne loginy (sprawdzane przy rejestracji) jednoznacznie wskazują na dane konto.

Ten post edytował Rzast 28.09.2006, 10:18:23

To co zrobiłeś jest beznadziejne - pobierasz z bazy uzytkowników którzy mają takie same hasła! A takie same hasła moze miec paru userow. Wiec wynik moze zwrocic ich kilku - skad wiesz ktory to. W Twoim przpadku addslashes zupełnie wystarczy. Oczywiście przy rejestracji najlepiej zabron pewnych znakow w loginie, zeby nie sprawial trudnosci - najlepiej zostawic znaki alfanumeryczne, podkreslenia i spacje

MatheW: Przyjżałeś się? Ale tak naprawdę uważnie?
Piszesz:

a w kodzie jest:

[PHP] pobierz, plaintext 
<?php
if (mysql_num_rows($wynik)>=1){//jeżeli jest jakiś user (userzy) o takim haśle...
  $ok=true;  //ustaw zmienną pomocniczą 
  while (($dana=mysql_fetch_row($wynik))&&($ok==true)){// dekoduj wynik z bazy dopóki pomocnicza prawdziwa
	if ($dana[1]==$_POST['login'])){  //jeżeli jest taki login to...
	  //Zalogowany
	  $ok=false;  //skasuj pomocniczą
	  $_Session['id']=$wynik[0]; //ustaw sesję
 ...itd
?>
[PHP] pobierz, plaintext 

Czy wytłumaczyć dokładniej?
pozdrawiam

To jest bez sensu... a jeśli w bazie masz założymu 1 000 000 userów gdzie 10 000 na takie same hasło... Wtedy zalogowanie jednocześnie 1 000 userów, obciąży serwer. Po co tak robić?

Lepiej zrobić tak:
Login: [A-Za-Z0-9_-]
Hasło: tu już dowolnie i tak hasło trzymamy w bazie jako md5, wiec dodanie jakichkolwiek znaków ' " które mogłby by spowodować zmiane zapytania nic tu nie dadzą.

Po co sobie utrudniać życie i kombinować?

Witam,

Czytam wątek już drugi raz (pierwszy raz ok. 3 miesiące temu, kiedy php to było dla mnie jeszcze nowość) i dalej nie jestem pewien co do sposobu zabezpieczenia.


Do tej pory używałem ctype_digit() do liczb, oraz htmlspecialchars() do reszty.
Ogólnie to wolałbym używać zamiast htmlspecialchars() funkcję addslashes(), ale kilka postów zamieszczonym na tym forum skutecznie zniechęciło mnie do niej. A mianowicie teksty typu: "A ja podwójnie robię addslashes", jakieś wyrażenia regularne, cuda nie widy..

Czy istnieje możliwość na 'obejście' addslashes()? Tzn przekazać do zmiennej nie wyeskejpowany cudzysłów (podwójny czy pojedyńczy) ?


ps. addslashes() dlatego, że zauważyłem iż MySQL wykonuje swego rodzaju stripslashes() na przychodzących danych, więc oszczędza to miejsce i nie trzeba dekodować później danych z wartości html'owych.


I o co chodzi z tym poruszeniem na temat UNION?
Przeczytałem artykuł http://www.really-fine.com/SQL_union.html i mniej więcej wiem na czym to polega..
Jeśli wyeskejpuje zmiennę lub sprawdze czy są liczbowe, to powinienem być bezpieczny przed tym, racja?



Nie potrzebuję alternatyw do wspomnianych funkcji (czytać manuala potrafię ) , jedynie potwierdzenie od kogoś doświadczonego, czy addslashes() to 100% zabezpieczenie przed cudzysłowiami (nie SQL Injection).
Oczywiście, post Nospora polecający używanie addslashes() przy zmiennych tekstowych daje mi 99% pewności, iż to tylko moja paranoja, ale ten 1% to o 1% za dużo niepewności


Swoją drogą, czy składnia typu

[PHP] pobierz, plaintext 
<?php
"SELECT * FROM table WHERE cos = '".$_POST."'";
?>
[PHP] pobierz, plaintext 

[bez tych slashy..]
ma jakieś walory pod względem bezpieczeństwa? Używam ".$zmienna." tylko dlatego, że edytor mi wtedy ładnie koloruje taką składnie, ale kto wie, może to coś daje 'gratis'? Wydajność? Bezpieczeństwo?



Dzięki z góry za pomoc w tej sprawie,
Paziek.

http://pl.php.net/manual/pl/function.mysql-escape-string.php

Jarod: Dzięki ale nie dzięki ;o

Po pierwsze, cytujesz fragment postu i odpowiadasz na ten fragment (nawet jak by go wyjąć z kontekstu) czymś zupełnie innym :/ Zadatki na polityka tutaj widzę

Po drugie, tak jak napisałem, nie potrzebuje alternatywy do wspomnianych funkcji, ani gotowego rozwiązania na SQL Injection, koduje swoje aplikacje 'w miarę potrzeb' i potrafię posługiwać się manualem oraz goglami.
Przeczytałem już tyle artykułów oraz postów na forum, że wiem wystarczająco dużo na ten temat.



Chciałem się tylko dowiedzieć, czy istnieje jakiś bug, dziura, sposób, cokolwiek w funkcji addslashes(), który umożliwiłby wprowadzenie do zmiennej nie wyeskejpowanego cudzysłowia, bo nieco zwątpiłem w tą funkcję, zapewne nadinterpretacją kilku postów. To (prawie) wszystko.


Jakiś .. chakier się wypowie?

Tak, istnieje taki bug. Nazywa się on:

$slashedVar=str_replace('\"','"',addslashes($sourceVar));

Tylko to programista musiałby go popełnić.. Moim zdaniem, masz faktycznie paranoję


I na koniec: Jarod dobrze ci napisał - do escepowania zmiennych, które umieszczasz w zapytaniu SQL służy mysql_real_escape_string().

I na drugi koniec: ani addslashes() ani htmlspecialchars() nie służą do tego, do czego próbujesz je użyć (patrz punkt wyżej). htmlspecialchars() stosujesz w momencie wyświetlania treści na stronie, aby zabezpieczyć się przed złośliwym działaniem właśnie na poziomie przeglądarki (HTMLa) a nie bazy.

php5, pdo i podpinanie, a skończą się wam problemy z addslashes(), mysql_real_escape_string() i magic_quotes

Ten post edytował L00zak 27.04.2007, 23:41:34

Czy ktoś, kto się na tym zna może mi odpowiedzieć:

Jest tu wiele sprzecznych wypowiedzi

I czy "mysql_escape_string" w całkowicie wyklucza możliwość przeprowadzenia ataku SQL Injection, czy konieczne są jakieś modyfikacje zapytań (jak w pierwszym poście)? I proponuję administracji posprzątać temat, bo po przeczytaniu nic mi się kupy nie trzyma:P

Stosuję mysql_escape_string + filtrowanie danych i moim zdaniem jest to w zupełności bezpieczne.

A przy okazji jak filtrować na poziomie postgresql'a?

EDIT: @radex_p - bo nie znalazłem odpowiednika dla postgresql'a

Ten post edytował Jarod 6.05.2007, 19:20:47

skoro mysql_escape_string (nie licząc standardowych procedur filtrujących) jest good, to czemu nie użyć podobnej funkcji przeznaczonej dla postgre'a, lub PHP'owskiej wbudowanej?

są sytuacje kiedy da się ją obejśc, nie jest tajemnicą że najlepiej stosować tzw. prepared statements. więcej: http://ilia.ws/archives/103-mysql_real_esc...Statements.html

Ten post edytował sopel 7.05.2007, 00:06:10

Witam.
Przeczytałem ten temat dwa razy. Dwa razy dostałem oczopląsu i palpitacji serca.
Temat niby jeden, ale skaczecie od wątku do wątku. Oszaleć można.
Postaram się w skrócie podsumować poprzednie wypowiedzi, zanim przejdę do swojego pytania,
jako że poprzednie podsumowania ułatwiły mi czytanie tego wątku.

1. Należy sprawdzać czy liczba jest liczbą, to znaczy że jeśli przesyłamy urlem id rekordu z tabeli musimy sprawdzić czy jest on liczbą.
2. Dodawanie ukośników przez addslashes() lub mysql_real_escape_string() w zmiennych typu string.
(Z tekstu tutaj wyczytałem że mysql_real_escape_string() robi to lepiej. Czy tak jest i dlaczego ?)
3. Ostatnim problemem z SQL-Injection jakiego zdołałem się tutaj doczytać jest słowo kluczowe SQL 'UNION'
dzięki któremu można pobrać więcej danych.

W mojej opinii nie należy trząść portkami przed UNION jeśli zamiast gwiazdki po SELECT wypisuje się nazwy pól które chce się pobrać z tabeli. Jeśli się mylę poprawcie mnie.

Moje pytanie(oprócz tego w punkcie drugim):
Chciałbym się dowiedzieć jak mam usunąć ze zmiennej wszystkie spacje nie tylko te z przodu i z tyłu - trim()
Mam z tym problem bo spacje można zapisać jeszcze w inny sposób niż ' ' a ja niestety na tych metodach zapisu się nie znam.

Poniżej przedstawiłem swoją metodę dodającą do łańcucha znaków wsteczne ukośniki.
Prosiłbym o jakieś komentarze czy jest ona bezpieczna i czy zamiast addslashes powinienem zastosować mysql_real_escape_string()

[PHP] pobierz, plaintext 
<?php
public function sanitize($input, $force=false)
	{
	  if(!get_magic_quotes_gpc() || $force == true)
	  {
		if(is_array($input))
		{
			  foreach($input as $key => $val)
			  {
				$input[$key] = addslashes($val);
			  }
		  return $input;
		} else {
		  return addslashes($input);
		}
	  } else {
		return $input;
	  }
	}
?>
[PHP] pobierz, plaintext 

Dziękuję za przeczytanie i odpowiedź na te moje wypociny

To zależy gdzie się jej użyje:

[PHP] pobierz, plaintext 
<?php
 
  // 1, zabezpieczone przed SQL injection
  $_GET['name'] = $this->sanitize( $_GET['name'] );
  mysql_query( "SELECT * FROM some_table WHERE name = '{$_GET['name']}'" );
 
 
  // 2, niezabezpieczone przed SQL injection
  $_GET['sort'] = $this->sanitize( $_GET['sort'] );
  mysql_query( "SELECT * FROM some_table ORDER BY {$_GET['sort']}" );
 
?>
[PHP] pobierz, plaintext 

A co do usuwania spacji to nie rozumiem problemu. Chodzi ci o to, że chcesz usunąć: ' ', ' ', '%20', itp? Tylko po co, skoro 2 i 3 przykład sam z siebie w spację się nie zamieni...
No ale zawsze możesz użyć str_replace" title="Zobacz w manualu PHP" target="_manual

Ten post edytował Kicok 12.05.2007, 17:26:40

Czyli nie ma się co zastanawiać tylko walnąć str_replace na ' '.
Ok dzięki.

Co do mysql_real_escape_string() to poniżej jest cytat z postu http://forum.php.pl/index.php?s=&showt...st&p=172835 calls MySQL's library function mysql_escape_string, which prepends backslashes to the following characters: NULL, \x00, \n, \r, \, ', " and \x1a.

addslashes() : Returns a string with backslashes before characters that need to be quoted in database queries etc. These characters are single quote ('), double quote ("), backslash (\) and NUL (the NULL byte).

Też mam (niestety) podobne odczucia...


Tak. Warto użyć do tego wyrażenia regularnego takiego jak to:

Powyższe wyrażenie sprawdza jeszcze ilość cyfr - raczej mało kto będzie miał ponad miliard rekordów


mysql_real_escape_string() uwzględnia zestaw znaków używany podczas łączenia się z bazą danych, więc będzie też poprawnie działać jeżeli używasz np. Unicode.

Co do ukośników - z tego co się orientuję, to kilka lat temu MySQL był wyjątkiem i ich wymagał, a inne bazy danych z którymi miałem do czynienia (PostgreSQL, MS SQL, Oracle) akceptowały podwójny apostrof (dwa apostrofy obok siebie). Obecnie także MySQL je akceptuję. Ja tutaj zalecam używanie mysql_escape_string() (dla MySQL) i pg_escape_string() (dla PostgreSQL), ew. podobnych funkcji (jest to opisane w dokumentacji PHP).

Przed wywołaniem tych funkcji warto także sprawdzić czy string wpisany do formularza nie jest za długi, i go obciąć. Warto także wywołać trim() - raczej nie ma sensu przechowywać dodatkowych spacji, które i tak nie będą wyświetlone.

Przy UNION jest tylko ważne aby zgadzała się ilość kolumn i ich typy były zgodne, dlatego "SELECT *" przed niczym nie chroni. Dlatego np. takie zapytanie zadziała:



Użyj czegoś takiego:

To polecenie zamienia kilka spacji (i innych "białych" znaków) na jedną spację. Nie usuwa ono jednak całkowicie spacji z początku i końca - trzeba albo to wyrażenie poprawić, albo dodatkowo użyć trim(). Jeżeli chcesz natomiast wyciąć wszystkie spacje, usuń spację z drugiego parametru.

Ktoś wcześniej wspomniał też o mod_rewrite i .htaccess - można tego użyć jako dodatkowego mechanizmu zabezpieczeń, trzeba tylko pilnować aby nigdzie na stronach nie pojawił się rzeczywisty adres stron w serwisie. Poza tym warto także pamiętać że zawsze można próbować zgadnąć nazwy stron i nazwy parametrów.

Poza tym jest jeszcze kwestia znaku komentarza "--" w SQL, i tzw. ataki wielofazowe, ale o tym nie chce mi się drugi raz pisać - zerknijcie sobie tutaj: Ataki SQL Injection

tylko po co te regexpy?

Właśnie po co skoro istnieje filter_ input()" title="Zobacz w manualu PHP" target="_manual

Po to żeby ci z php4 też mieli bezpieczne formularze