SQL injection i inne ataki

SQL injection i inne ataki

eska chojnice Zobacz profil	5.04.2012, 19:13:23 Post #1
Grupa: Zarejestrowani Postów: 44 Pomógł: 1 Dołączył: 16.09.2010 Ostrzeżenie: (0%)	Czy jeśli zablokuję znaki CODE '/\:?"<>\|; Mogę być na ogół pewny że nie grozi mi SQL injection ? Jakie są jeszcze typy ataków poprzez SQL i na czym polegają, dobrze jeszczy by było jak by ktoś powiedział jak się przed nim zabezpieczyć. jeśli nie będzie to tylko odsyłka do angielskiej strony będzie pomógł (IMG:style_emoticons/default/wink.gif) Ten post edytował eska chojnice* 5.04.2012, 19:24:55

Odpowiedzi (1 - 4)

droslaw Zobacz profil	5.04.2012, 20:27:06 Post #2
Grupa: Zarejestrowani Postów: 98 Pomógł: 33 Dołączył: 10.05.2011 Skąd: Krak Ostrzeżenie: (0%)	Blokowanie jakichkolwiek znaków to nie jest dobry pomysł. Czasami będzie trzeba je przechowywać w bazie. Zamiast tego dane powinno się escapować. Dla MySQL`a odpowiednią funkcją do tego celu jest mysql_real_escape_string(). Ta funkcja wstawi "\" przed niebezpiecznymi znakami i nie będą już groźne. Nie zapominij wstawiać wszystkich danych do zapytania w cudzysłowach. Jeśli dasz cudzysłowy, to kiedy użytkownik wpisze instrukcje np. w formularzu zostaną potraktowane jak dane. Tak może to wyglądać: [PHP] pobierz, plaintext // Odbieramy dane z formularza logowania. $login = mysql_real_escape_string($POST['login']); $password = mysql_real_escape_string($POST['password']); $query = "SELECT * FROM `users` WHERE `user_name` = '".$login."' AND `user_password` = PASSWORD('".$password."')"; // w $query masz teraz bezpieczne zapytanie. [PHP] pobierz, plaintext Możesz też skorzystać z PDO i jego bindowania para

eska chojnice Zobacz profil	5.04.2012, 20:52:33 Post #3
Grupa: Zarejestrowani Postów: 44 Pomógł: 1 Dołączył: 16.09.2010 Ostrzeżenie: (0%)	a jakie są jeszcze ataki?

droslaw Zobacz profil	5.04.2012, 21:16:33 Post #4
Grupa: Zarejestrowani Postów: 98 Pomógł: 33 Dołączył: 10.05.2011 Skąd: Krak Ostrzeżenie: (0%)	Ataki związane z SQL? Napisałem o wstrzykiwaniu kodu do instrukcji SELECT. Dużo gorsze może byś wstrzyknięcie kodu do instrukcji INSERT, UPDATE albo DELETE. Zabezpieczać się można w tych wypadkach w ten sam sposób. Dane potraktować funkcją mysql_real_escape_string() i koniecznie ograniczyć je w zapytaniu cydzysłowami. Dotyczy to danych nie tylko z formularza ale z każdego źródła, nawet plików na serwerze albo samej bazy danych. W ostatnim poście ucięło mi końcówkę. Miało być bindowanie parametrów. Zapomniałem też napisać o problemie jaki stwarza magic_quotes_gpc(). Jeśli magic_quotes jest włączone backslashe dodawane są automatycznie i trzeba najpierw je usunąć za pomocą funkcji stripslashes(). Żeby nie mieszać w kodzie aplikacji najlepiej zrobić to gdzieś na początku. Tak jak tu jest opisane.

thek Zobacz profil	5.04.2012, 23:09:29 Post #5
Grupa: Moderatorzy Postów: 4 362 Pomógł: 714 Dołączył: 12.02.2009 Skąd: Jak się położę tak leżę :D	Pozwolicie, że się wtrącę, ale jest już na tym forum wątek o sql injection... I to nawet przypięty. Czy naprawdę jest sens powtarzać dokładnie to samo co tam? Zamykam temat by nikt niepotrzebnie się nie rozpisywał.

2 Użytkowników czyta ten temat (2 Gości i 0 Anonimowych użytkowników)

0 Zarejestrowanych:

Tryb wyświetlania: Przełącz na: Standardowy · Linearny+ · Przełącz na: Drzewo

Aktualny czas: 26.12.2025 - 04:18

Hosting zapewnia