ďťż

[PHP] Slash'e - odwieczny problem Bezpieczeństwo i zapis/odczyt

       

Podstrony


telcocafe

F3Site ma błędy związanych z bezpieczeństwem SQL oraz slashami. Z naprawą pierwszego kłopotów być nie powinno, jednak drugie jest z tym powiązane.

Automatyczne dodawanie slashów zależy od konfiguracji serwera. To sprawia problem.

Zaaktualizowane
Tekst przesyłany jest metodą $_POST. Jak wiadomo, PHP doda do niego slashe. Potem slashe doda jeszcze funkcja mysql_real_escape_string(), więc będą podwójne (\\\\).

Co więc zrobić, by nie były one podwójne? Otwieram tabelę w programie MySQL Control Center i wygląda, jakby MySQL usunął niepotrzebne (\\). Jednak to jest chyba nieprawda.
Odczytuję z bazy dane z linijką na początku skryptu:
set_magic_quotes_runtime(1);
W polu textarea pojawiają się "\\" zamiast "\" (jak było wysłane metodą POST).

1. Czy automatyczne dodawanie slashów przez PHP jest wystarczające, by nie doszło do SQL Injection?
2. Jak najlepiej ten problem rozwiązać?
3. Czy wystarczy tylko zamienianie " na \", by nie doszło do SQL Injection (SET costam=" i w cudzysłowiach dopiero zmienna ", )?

:excl: Można to rozwiązać, sprawdzając czy GPC jest włączone i jeśli tak, zastosować stripslashes(), ale być może nie ma co tyle kombinować.
Użytkownik Ferrari edytował ten post 02 styczeń 2006, 17:17



(czy ona jest lepsza od mysql_escape_string() pod względem bezpieczeństwa?).

slashe to tylko jeden sposób kontroli danych przesyłanych do bazy danych. Jeżeli coś ma być liczbą to sprawdzaj "is_numeric", jeżeli coś ma nie mieć HTML/itd. - strip_tags, "proste" pola np. na login itd. nie powinny mieć znaków =, % i podobnych - kontrola/die. Zawsze też możesz używać dodatkowo base64_encode i base64_decode - w bazie zapisujesz ładny czysty łańcuch i masz spokój :)

  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • nvm.keep.pl

  • Sitedesign by AltusUmbrae.