SQL Injection/Insertion, Jak zapobiec włamaniu na stronę. |
SQL Injection/Insertion, Jak zapobiec włamaniu na stronę. |
14.07.2012, 22:38:30
Post
#381
|
|
Grupa: Zarejestrowani Postów: 565 Pomógł: 15 Dołączył: 11.10.2010 Ostrzeżenie: (20%) |
Jeśli będę używał PDO zamiast MySQL do łączenia się z bazą danych to jest mniejsze prawdopodobieństwo, że ktoś może wykorzystać SQL Injection ?
|
|
|
14.07.2012, 22:45:36
Post
#382
|
|
Grupa: Zarejestrowani Postów: 1 182 Pomógł: 115 Dołączył: 4.03.2009 Skąd: Myszków Ostrzeżenie: (0%) |
Po pierwsze nie zamiast MySQL, co najwyżej mysql_ .
Po drugie tylko jeśli będziesz używał zapytań preparowanych i podpinania parametrów, wtedy prawdopodobieństwo -> 0. Ten post edytował Mephistofeles 14.07.2012, 22:46:02 |
|
|
15.07.2012, 11:29:35
Post
#383
|
|
Grupa: Zarejestrowani Postów: 565 Pomógł: 15 Dołączył: 11.10.2010 Ostrzeżenie: (20%) |
A gdzie mogę zobaczyć przykład zapytań preparowanych ?
|
|
|
15.07.2012, 11:49:08
Post
#384
|
|
Grupa: Zarejestrowani Postów: 1 182 Pomógł: 115 Dołączył: 4.03.2009 Skąd: Myszków Ostrzeżenie: (0%) |
Stronę wcześniej w tym temacie .
|
|
|
15.07.2012, 13:37:13
Post
#385
|
|
Grupa: Zarejestrowani Postów: 565 Pomógł: 15 Dołączył: 11.10.2010 Ostrzeżenie: (20%) |
Czyli ten kod jest preparowaniem zmiennych, tak ?
|
|
|
15.07.2012, 13:51:12
Post
#386
|
|
Grupa: Zarejestrowani Postów: 709 Pomógł: 176 Dołączył: 24.10.2010 Ostrzeżenie: (0%) |
tak.
-------------------- http://d3ut3r.wordpress.com/ | mysql_* jest przestarzałe UŻYWAJ PDO!
|
|
|
24.07.2012, 22:48:55
Post
#387
|
|
Grupa: Zarejestrowani Postów: 565 Pomógł: 15 Dołączył: 11.10.2010 Ostrzeżenie: (20%) |
Dobra, po przeczytaniu lektury w tym temacie od dnia dzisiejszego będę korzystał z PDO.
Dzięki A w jaki bezpieczny sposób wyciągać dane użytkowników za pomocą PDO ? |
|
|
21.01.2013, 22:12:19
Post
#388
|
|
Grupa: Zarejestrowani Postów: 4 Pomógł: 0 Dołączył: 21.01.2013 Ostrzeżenie: (0%) |
Witam
Chciałbym potwierdzić kilka rzeczy: 1. Czy funkcja mysqli_real_escape_string jest tak samo nic niewarta jak mysql_real_escape_string? Oczywiście na dzień dzisiejszy (PHP 5.4). 2. Czy w przypadku liczb całkowitych rzutowanie na inta jest wystarczającym zabezpieczeniem czy są jakieś cudowne metody pozwalające obejść to? 3. Czy htmlentities chroni przed XSS? I od razu chciałbym zaznaczyć że nie jestem upartym durniem broniącym się rękami i nogami przez używaniem prepared statements, tylko jakiś czas temu przeczytałem to i stwierdzenie tam zawarte nie daje mi spokoju: Cytat SQL injections are not the reason to write slower code, php mysql driver provides several ways to escape the input.
|
|
|
21.01.2013, 22:17:21
Post
#389
|
|
Grupa: Zarejestrowani Postów: 2 148 Pomógł: 230 Dołączył: 26.03.2008 Ostrzeżenie: (0%) |
1. Czy funkcja mysqli_real_escape_string jest tak samo nic niewarta jak mysql_real_escape_string? Oczywiście na dzień dzisiejszy (PHP 5.4). Obie są stworzone do tego, co mają robić, i stwierdzenie, że są nic nie warte to pitolenie po całości. 2. Czy w przypadku liczb całkowitych rzutowanie na inta jest wystarczającym zabezpieczeniem czy są jakieś cudowne metody pozwalające obejść to? Wystarczy 3. Czy htmlentities chroni przed XSS? Między innymi tak. -------------------- ET LINGUA EIUS LOQUETUR IUDICIUM
|
|
|
21.01.2013, 23:19:03
Post
#390
|
|
Grupa: Zarejestrowani Postów: 4 Pomógł: 0 Dołączył: 21.01.2013 Ostrzeżenie: (0%) |
Dzięki z szybką i konkretną odpowiedz.
Co do 1. to chyba zostałem źle zrozumiany też wydaje mi się (bo brak mi wiedzy na ten temat) że te funkcja działa jak powinna, lecz wcześniej w tym wątku, albo gdzieś indziej, wyczytałem że ma problemy z kodowaniem znaków itp. itd. To jeszcze tak dla pewności - używanie mysqli_real_escape_string jest tak samo efektywne (albo chociaż porównywalne) z używaniem prepared statements? Oczywiście jeśli chodzi o zabezpieczenie przez SQL Injection. |
|
|
21.01.2013, 23:38:04
Post
#391
|
|
Grupa: Zarejestrowani Postów: 2 148 Pomógł: 230 Dołączył: 26.03.2008 Ostrzeżenie: (0%) |
Dzięki z szybką i konkretną odpowiedz. Co do 1. to chyba zostałem źle zrozumiany też wydaje mi się (bo brak mi wiedzy na ten temat) że te funkcja działa jak powinna, lecz wcześniej w tym wątku, albo gdzieś indziej, wyczytałem że ma problemy z kodowaniem znaków itp. itd. To jeszcze tak dla pewności - używanie mysqli_real_escape_string jest tak samo efektywne (albo chociaż porównywalne) z używaniem prepared statements? Oczywiście jeśli chodzi o zabezpieczenie przez SQL Injection. Musisz przeczytać do czego służy jedno i drugie... bo jak w ciemno będziesz wszędzie stosował "funkcje zabezpieczające" nie rozumiejąc co one robią, to prawdopodobnie i tak zostawisz luki, pomimo ich zastosowania. -------------------- ET LINGUA EIUS LOQUETUR IUDICIUM
|
|
|
22.01.2013, 17:49:30
Post
#392
|
|
Grupa: Zarejestrowani Postów: 4 Pomógł: 0 Dołączył: 21.01.2013 Ostrzeżenie: (0%) |
Na dobrą sprawę moim problemem nie jest niewiedza jeśli chodzi o techniki obrony przed SQL Injection, chodzi bardziej o to że nie mam pojęcia jak wygląda taki atak (hakowanie mnie kompletnie nie interesuje), oczywiście poza teorią i prostymi przykładami - tylko jak dla mnie przed tym chroniło magic quotes, a tu czytam że w 5.4 zostało praktycznie rzecz ujmując wywalone. Przez co trochę zgłupiałem.
Ale poczytałem na spokojnie i rozwiałem większość swoich wątpliwości. Swoją drogą polecam tą stronę - wszystko w jednym miejscu i konkretnie na temat. Mam jeszcze dwa pytania na które nie znalazłem konkretnych odpowiedzi. W przypadku gdy chcę umieścić w bazie treść np. komentarza, posta, wiadomości itp. czyli gdy jest duża dowolność wpisywanych danych oraz ma być to później wyświetlone. Widzę dwa rozwiązania: 1. Zdekodować taką treść używając htmlentities i zapisać w takiej postaci w bazie. Niby nie jest to złe rozwiązanie ale ciężko będzie takie coś edytować z poziomu bazy danych. 2. Zastosować przed umieszczaniem w bazie mysqli_real_escape_string, a przy wyświetleniu użyć htmlentities. Nie ma to wady pierwszej metody ale nie jestem pewien czy samo mysqli_real_escape_string wystarczy. Czy do switcha można wystrzyknąć złośliwy kod? Czyli czy takie coś:
jest potencjalnie niebezpieczne? Wiem że to ogólnie zła praktyka bo uczy złych nawyków, ale chodzi mi konkretnie czy switch jest narażony na taki atak. Ten post edytował Cadmer 22.01.2013, 17:50:25 |
|
|
22.01.2013, 18:08:50
Post
#393
|
|
Grupa: Zarejestrowani Postów: 2 148 Pomógł: 230 Dołączył: 26.03.2008 Ostrzeżenie: (0%) |
W przypadku gdy chcę umieścić w bazie treść np. komentarza, posta, wiadomości itp. czyli gdy jest duża dowolność wpisywanych danych oraz ma być to później wyświetlone. Widzę dwa rozwiązania: 1. Zdekodować taką treść używając htmlentities i zapisać w takiej postaci w bazie. Niby nie jest to złe rozwiązanie ale ciężko będzie takie coś edytować z poziomu bazy danych. 2. Zastosować przed umieszczaniem w bazie mysqli_real_escape_string, a przy wyświetleniu użyć htmlentities. Nie ma to wady pierwszej metody ale nie jestem pewien czy samo mysqli_real_escape_string wystarczy. 1 metoda odpada zupełnie, bo jest to bardzo zła praktyka, jeśli chodzi o cały projekt. Co do reszty, przeanalizuj poniższy przykład:
I sam mi odpowiedz na pytanie czemu ten urywek kodu jest podatny na ataki. Czy do switcha można wystrzyknąć złośliwy kod? Czyli czy takie coś:
jest potencjalnie niebezpieczne? Wiem że to ogólnie zła praktyka bo uczy złych nawyków, ale chodzi mi konkretnie czy switch jest narażony na taki atak. To też zależy. Z reguły nie, ale w przypadku udziwniania, też można zostawić lukę pozwalającą na włamanie. -------------------- ET LINGUA EIUS LOQUETUR IUDICIUM
|
|
|
22.01.2013, 22:22:41
Post
#394
|
|
Grupa: Zarejestrowani Postów: 4 Pomógł: 0 Dołączył: 21.01.2013 Ostrzeżenie: (0%) |
Cóż można tam wstawić ID jakiegokolwiek użytkownika, co niekoniecznie jest błędem zależy co miałby ten kod robić. Nie powinno się raczej nigdy za to wybierać wszystkich kolumn z tabeli przy pomocy * z wielu powodów. Jeśli chodziło Ci o coś innego to tak jak pisałem wcześniej nie znam się na magicznych jak dla mnie sposobach wczepiania kodu zapytań.
|
|
|
3.02.2013, 18:05:56
Post
#395
|
|
Grupa: Zarejestrowani Postów: 55 Pomógł: 2 Dołączył: 15.09.2012 Ostrzeżenie: (0%) |
1 metoda odpada zupełnie, bo jest to bardzo zła praktyka, jeśli chodzi o cały projekt. Mógłbyś jakoś rozwinąć ? Właśnie jestem na etapie 'zabezpieczania' danych z postów i komentarzy i miałem zamiar użyć htmlspecialchars lub htmlentities. Oczywiście nie w kontekście SQL Injection, bo od tego mam PDO, ale np ataków XSS. Ten post edytował Piotrbaz 3.02.2013, 18:07:07 -------------------- $piotrbaz->get_Signature();
|
|
|
3.02.2013, 21:40:08
Post
#396
|
|
Grupa: Zarejestrowani Postów: 2 148 Pomógł: 230 Dołączył: 26.03.2008 Ostrzeżenie: (0%) |
Cóż można tam wstawić ID jakiegokolwiek użytkownika, co niekoniecznie jest błędem zależy co miałby ten kod robić. Nie powinno się raczej nigdy za to wybierać wszystkich kolumn z tabeli przy pomocy * z wielu powodów. Jeśli chodziło Ci o coś innego to tak jak pisałem wcześniej nie znam się na magicznych jak dla mnie sposobach wczepiania kodu zapytań. Nie, zupełnie nie o to chodzi. Jako user_id podstaw sobie (zakładam, że w tabeli są kolumny id, username, password): Kod -1 UNION SELECT 1, DATABASE(), 3 I zobacz co się stanie. Zabezpieczone przez mysql_real_escape_string(), a luka nadal jest. Magia, co? Mógłbyś jakoś rozwinąć ? Właśnie jestem na etapie 'zabezpieczania' danych z postów i komentarzy i miałem zamiar użyć htmlspecialchars lub htmlentities. Oczywiście nie w kontekście SQL Injection, bo od tego mam PDO, ale np ataków XSS. Dane do wyświetlania zabezpiecza się właśnie przy wyświetlaniu, a nie ładuje do bazy już w zmienionej formie. Chodzi o integralność danych i czytelność tego co wpisują użytkownicy. Ten post edytował pyro 3.02.2013, 21:42:13 -------------------- ET LINGUA EIUS LOQUETUR IUDICIUM
|
|
|
3.02.2013, 23:11:32
Post
#397
|
|
Grupa: Zarejestrowani Postów: 55 Pomógł: 2 Dołączył: 15.09.2012 Ostrzeżenie: (0%) |
No ok, czyli htmlspecialchars() stosuje przed wyświetleniem danych użytkownikowi. Czy przed zapisem danych do bazy ograniczam się tylko zabezpieczeniem przed SQL Injection ? (co załatwia podpinanie w PDO)
Ten post edytował Piotrbaz 3.02.2013, 23:12:03 -------------------- $piotrbaz->get_Signature();
|
|
|
3.02.2013, 23:17:57
Post
#398
|
|
Grupa: Zarejestrowani Postów: 2 148 Pomógł: 230 Dołączył: 26.03.2008 Ostrzeżenie: (0%) |
Tak, prepared statements w PDO powinny załatwić sprawę. No chyba że integer przez przypadek potraktujesz jako string.
Ten post edytował pyro 3.02.2013, 23:19:18 -------------------- ET LINGUA EIUS LOQUETUR IUDICIUM
|
|
|
4.03.2013, 12:04:37
Post
#399
|
|
Grupa: Zarejestrowani Postów: 82 Pomógł: 1 Dołączył: 18.09.2011 Ostrzeżenie: (0%) |
Czesc,
troche tego duzo, szczerze, nie mam czasu czytac wszystkich stron.Ale mam pytanie apropo mysql_real_escape_string. Wszyscy pisza, zeby uzywac do zmiennych przed wstawieniem do zapytania... a nie mozna finalnego zapytania w calosci przepuscic przez to? Czy to bedzie mialo jakis nieoczekiwany efekt? |
|
|
4.03.2013, 12:25:07
Post
#400
|
|
Grupa: Zarejestrowani Postów: 4 298 Pomógł: 447 Dołączył: 16.11.2006 Ostrzeżenie: (0%) |
Zostaw te bzdury zaczynające się od mysql_* w manualu i przejdź na PDO, a nie będziesz mieć takich problemów.
-------------------- Nie udzielam pomocy poprzez PW i nie mam GG.
Niektóre języki programowania, na przykład C# są znane z niezwykłej przenośności (kompatybilność ze wszystkimi wersjami Visty jest wiele warta). |
|
|
Wersja Lo-Fi | Aktualny czas: 28.03.2024 - 18:18 |