SQL Injection/Insertion, Jak zapobiec włamaniu na stronę. |
SQL Injection/Insertion, Jak zapobiec włamaniu na stronę. |
8.05.2005, 19:08:08
Post
#41
|
|
Grupa: Zarejestrowani Postów: 1 190 Pomógł: 27 Dołączył: 23.04.2005 Ostrzeżenie: (0%) |
Cytat(Peter Riley @ 2005-05-08 17:43:03) oczywiscie pozostaje sprawdzenie czy nadeslane dane mieszcza sie w dozwolonym zakresie, ale to juz inna historia. Możesz rozwinąć? -------------------- ”Godzina nauki w życiu nowoczesnego apostoła jest godziną modlitwy.”
(św. Josemaría Escrivá, Droga, 335) |
|
|
8.05.2005, 19:47:55
Post
#42
|
|
Grupa: Zarejestrowani Postów: 18 Pomógł: 0 Dołączył: 7.05.2005 Ostrzeżenie: (0%) |
Cytat(J4r0d @ 2005-05-08 18:08:08) Cytat(Peter Riley @ 2005-05-08 17:43:03) oczywiscie pozostaje sprawdzenie czy nadeslane dane mieszcza sie w dozwolonym zakresie, ale to juz inna historia. Możesz rozwinąć? Po prostu musimy sprawdzic, czy przeslane wartosci maja odpowiedni przedzial, czyli np. wpisana ilosc sztuk nie przekracza stanu magazynu. W przypadku wartosci tekstowych mozna porownac wyszukac ciagu w zadeklarowanej wczesniej tablicy lub uzyc switch of. Jednak to wszystko nie ma nic wspolnego ze sql injection, przed ktorym pelna obrone zapewnia defaultowa konfguracja php, a jesli wylaczymy magic quote, pozostanie addslashes. |
|
|
8.05.2005, 22:14:33
Post
#43
|
|
Grupa: Zarejestrowani Postów: 853 Pomógł: 25 Dołączył: 27.08.2003 Skąd: Katowice Ostrzeżenie: (0%) |
Cytat(Peter Riley @ 2005-05-08 18:43:03) addslash lub magic quote zalatwia calkowicie sprawe sql injection smiem twierdzic ze jest to zbyt odwazne stwierdzenie. wyobraz sobie taka sytuace : URL: www.strona.php?articleid=12 filtrujemy: $id = addslashes($_GET['articleid']) wstawiamy w zapytanie : query = 'SELECT * FROM articles WHERE id='.$id; i teraz np. URL www.strona.php?articleid=12 OR 1 jak widzisz w tym przykladzie (co prawda dosc naiwnym) addslashes nie zalatwilo sprawy... -------------------- "If debugging is the process of removing bugs, then programming must be the process of putting them in..."
sobstel.org |
|
|
9.05.2005, 00:14:50
Post
#44
|
|
Grupa: Zarejestrowani Postów: 560 Pomógł: 0 Dołączył: 15.07.2003 Skąd: Kwidzyn Ostrzeżenie: (0%) |
panowie!!!!
juz ktos pisal o tym ze wiemy co "spodziewamy" sie otrzymac jesli chodzi o liczby to nie addslashes tylko intval() lub settype() $id = intval($_GET['articleid']); i jesli gosc wklepie tam cokolwiek to i tak bedzie zutowane na liczbe nawet ze wzglegow optymalizacji lepiej jest wykonac zapytanie SELECT * FROM table WHERE id=10 niz SELECT * FROM table WHERE id='10' poniewaz MySQL nie musi robic konwersji addslashes uzywamy jesli mamy doczynienia z wartosciami textowymi lub mieszanymi tak na marginesie to zadna funkcja nie zwalnia od myslenia! Ten post edytował Kinool 9.05.2005, 00:20:28 -------------------- |
|
|
9.05.2005, 01:28:44
Post
#45
|
|
Grupa: Zarejestrowani Postów: 18 Pomógł: 0 Dołączył: 7.05.2005 Ostrzeżenie: (0%) |
Cytat(sopel @ 2005-05-08 21:14:33) smiem twierdzic ze jest to zbyt odwazne stwierdzenie. To chyba oczywiste, ze musimy sprawdzic czy liczby rzeczywiscie sa liczbami, przy okazji sprawdzajac ich zakres. Zreszta pisalem o tym wyzej. Dodam tylko, ze ja sklaniam sie raczej do sprawdzania typu, a nie konwersji na sile. Jesli typ sie nie zgadza, to mail do admina i die(). Nie jest to odwazne stwierdzenie tylko fakt. Zaloze sie, ze ci co usuwaja UNION i sredniki z ciagow, na wszelki wypadek klikaja "zastosuj" w windowsowych okienkach tuz przed kliknieciem "ok" :-) Ten post edytował Peter Riley 9.05.2005, 01:32:48 |
|
|
14.05.2005, 20:58:57
Post
#46
|
|
Grupa: Zarejestrowani Postów: 243 Pomógł: 0 Dołączył: 30.11.2003 Ostrzeżenie: (0%) |
Dorzucę się do tego wątku i powiem, że moim zdaniem najlepszym zabezpieczeniem jest:
1. ustawienie w php.ini opcji get_magic_quotes_gpc na ON 2. stosowana równolegle z powyższym funkcja czyszcząca otrzymane dane - od razu uprzedzam, że wbrew nazwie nie dotyczy ona tylko danych przesyłanych metodą POST:
3. Funkcja zapewniająca dodatkowe filtrowanie dla identyfikatorów, przekazywanych w URL'u:
Zastosowanie:
Jakieś uwagi? Pozdrawiam, K |
|
|
14.05.2005, 21:44:37
Post
#47
|
|
Grupa: Zarejestrowani Postów: 657 Pomógł: 2 Dołączył: 15.08.2003 Skąd: Łódź Ostrzeżenie: (0%) |
Cytat(Peter Riley @ 2005-05-08 19:43:03) Cytat(J4r0d @ 2005-05-08 16:56:50) Bezpieczeństwo - szkoda czasu? Nie dla mnie :roll2: A co z bezpieczenstwem ma wspolnego kasowanie ciagow typu UNION ze zmiennej, w ktorej i tak kazdy apostrof zostanie wysleszowany? Nic. addslash lub magic quote zalatwia calkowicie sprawe sql injection, oczywiscie pozostaje sprawdzenie czy nadeslane dane mieszcza sie w dozwolonym zakresie, ale to juz inna historia. Hyh... kompletnie się z Tobą nie zgodzę :] Union da się wiele razy wykorzystać nie stosując nawet jednego apostrofu! Więc samo używanie addslashes() w przypadku posiadania MySQL 4 nie jest bezpieczne ! -------------------- |
|
|
16.05.2005, 23:02:57
Post
#48
|
|
Grupa: Zarejestrowani Postów: 8 Pomógł: 0 Dołączył: 10.10.2004 Ostrzeżenie: (0%) |
a takie pytanko jeszcze.
czy umozliwienie stosowania wszystkich znakow np. spacji przy tworzeniu loginu podczas rejestracji jest niebezpieczne ? |
|
|
18.05.2005, 14:56:35
Post
#49
|
|
Grupa: Zarejestrowani Postów: 8 Pomógł: 0 Dołączył: 10.10.2004 Ostrzeżenie: (0%) |
wszystkie znaki - oczywiscie przy wlaczanej dyrektywie gpc_magic_quotes
ktuvok - uzywam podobnego mechanizmu i na razie nie ma problemow (moze dlatego, ze nikt nie robil testow, albo nie zauwazono, ze cos jest nie tak). dodatkowo uzywam htmlspecialchars. Ten post edytował bolas 18.05.2005, 14:58:44 |
|
|
22.05.2005, 10:18:04
Post
#50
|
|
Grupa: Zarejestrowani Postów: 581 Pomógł: 0 Dołączył: 21.07.2003 Skąd: Jasło Ostrzeżenie: (0%) |
Nie wiem czy był dawany ten link lecz jeśli nie to prosze o usunięcie postu, a takto ciekawy art do przeczytanie http://www.computerworld.pl/artykuly/31505.html
-------------------- „Człowiek jest wielki nie przez to, co posiada, lecz przez to, kim jest;
nie przez to, co ma, lecz przez to, czym dzieli się z innymi.” Jan Paweł II |
|
|
6.07.2005, 13:03:21
Post
#52
|
|
Grupa: Zarejestrowani Postów: 8 Pomógł: 0 Dołączył: 6.07.2005 Ostrzeżenie: (0%) |
Cytat(Vengeance @ 2005-05-14 20:44:37) Union da się wiele razy wykorzystać nie stosując nawet jednego apostrofu! Więc samo używanie addslashes() w przypadku posiadania MySQL 4 nie jest bezpieczne ! Mam w takim razie pytanko: w jaki sposób wykonać SQL Injection w takim skrypcie:
Jakoś nie widzę tutaj możliwości wykorzystania UNION poprzez SQL Injection Ten post edytował logeen 6.07.2005, 14:32:51 |
|
|
7.07.2005, 19:53:24
Post
#53
|
|
Grupa: Zarejestrowani Postów: 657 Pomógł: 2 Dołączył: 15.08.2003 Skąd: Łódź Ostrzeżenie: (0%) |
Wiadomym jest, że nie w każdym się da... ale są przypadki gdzie tak jest. Przecież w UNION najczęściej chodzi o wyciągnięcie danych... więc nie musisz używać apostrofu. Gdy ktoś zrobi błąd w takim miejscu, iż użycie apostrofu nie jest wymagane (a najczęściej jest właśnie tylko w dyrektywach WHERE) to droga otwarta.
-------------------- |
|
|
7.07.2005, 20:04:31
Post
#54
|
|
Grupa: Zarejestrowani Postów: 90 Pomógł: 2 Dołączył: 3.12.2004 Ostrzeżenie: (0%) |
Nie zapominajmy, że przy union włamywacz musi znać nazwę tabeli i pól w tabeli mysql, a w przypadku, jeśli ktoś pisze skrypty sam i nie używa gotowców, prawdopodobieństwo, że włamywacz odgadnie nazwę tabeli i pola jest IMHO bardzo małe.
|
|
|
7.07.2005, 20:07:40
Post
#55
|
|
Grupa: Zarejestrowani Postów: 657 Pomógł: 2 Dołączył: 15.08.2003 Skąd: Łódź Ostrzeżenie: (0%) |
IMHO pokaz mi programiste co nie trzyma loginow i hasel w tabeli nazwą zblizonej do 'users' :]
Pozatym... wywolujac kontrolowane bledy SQL mozna czesto poznac spora czesc struktury bazy SQL. Ale ogólnie to masz racje -------------------- |
|
|
7.07.2005, 21:03:48
Post
#56
|
|
Grupa: Zarejestrowani Postów: 8 Pomógł: 0 Dołączył: 6.07.2005 Ostrzeżenie: (0%) |
Cytat(Vengeance @ 2005-07-07 18:53:24) Gdy ktoś zrobi błąd w takim miejscu, iż użycie apostrofu nie jest wymagane (a najczęściej jest właśnie tylko w dyrektywach WHERE) to droga otwarta. Tutaj się zgodzę, ale powiedzcie mi w takim razie, po co sztucznie wywalać UNION ze wszystkich danych podstawianych do zapytania, jeżeli można je tak zabezpieczyć, że nigdy nie będzie możliwości wykonania SQL injection (np. tak jak zaprezentowałem powyżej)? Czy to nie jest paranoja? Gdyby programiści IPB byli tak na to wyczuleni, to na tym forum w treści postów w ogóle nie dałoby się wpisać słowa "UNION" i jeszcze kilku innych, a jak widać da się |
|
|
7.07.2005, 23:35:32
Post
#57
|
|
Grupa: Zarejestrowani Postów: 657 Pomógł: 2 Dołączył: 15.08.2003 Skąd: Łódź Ostrzeżenie: (0%) |
Dlatego, że w takim forum wykonuje się masę zapytań i nie zawsze wszystkie 100% sprawdzisz. Więc lepiej w jednym miejscu filtrować niebezpieczne dane... by potem mieć pewność że do każdego zapytania dotrą w odpowiedniej formie... i że nie zapomnieliśmy gdzieś czegoś filtrować.
-------------------- |
|
|
8.07.2005, 01:01:33
Post
#58
|
|
Grupa: Zarejestrowani Postów: 8 Pomógł: 0 Dołączył: 6.07.2005 Ostrzeżenie: (0%) |
To jasne, ale zależy, co rozumiesz przez "filtrować". Jeżeli filtrowaniem nazywamy np. używanie funkcji "addslashes" czy "intval", to OK. Ale jeżeli to ma polegać na bezcelowym usuwaniu np. wszystkich wystąpień słowa "UNION" i innych podobnych z danych przesyłanych przez użytkownika, a podstawianych do zapytania, to ja tego nie rozumiem. Po co to usuwać, skoro i tak w żaden sposób nie może zaszkodzić, jeżeli odpowiednio przefiltrujemy dane? Na dodatek przez takie postępowanie zupełnie niepotrzebnie eliminujemy sobie możliwość wstawienia do bazy danych niektórych słów, co może być akurat potrzebne. Spróbujcie napisać np. tutorial używania unii w SQL, jeżeli z każdego tekstu wstawianego do bazy będziecie czyścić to słowo ;-)
Jak ktoś nie filtruje danych, to i tak żadne usuwanie "UNION" itp. mu nie pomoże, bo SQL injection można wykonać na wiele innych sposobów, kiedy nie przefiltrujemy danych wejściowych... |
|
|
8.07.2005, 01:16:42
Post
#59
|
|
Grupa: Zarejestrowani Postów: 657 Pomógł: 2 Dołączył: 15.08.2003 Skąd: Łódź Ostrzeżenie: (0%) |
1. A kto mówi że strona musi traktować o czymś gdzie wystąpi UNION.
2. Zobacz ile skryptów (np. phpbb) jest podatnych na tego typu ataki -------------------- |
|
|
8.07.2005, 02:34:26
Post
#60
|
|
Grupa: Zarejestrowani Postów: 8 Pomógł: 0 Dołączył: 6.07.2005 Ostrzeżenie: (0%) |
ad.1) Czyli co? Jeżeli zamierzasz zbudować np. forum dyskusyjne przeznaczone do dyskusji na temat języka SQL, to nie będzie się go dało zabezpieczyć, bo w takim przypadku usuwanie "UNION" z treści wysyłanych postów jest absolutnie nie do przyjęcia, a tylko to dałoby wystarczające zabezpieczenie?
ad.2) Skrypty są podatne, ponieważ programiści zapomnieli przefiltrować dane. Gdyby to zrobili, to by nie były podatne. Usuwanie "UNION" tutaj nic nie zmieni, ponieważ jeżeli dane wejściowe potraktujemy odpowiednio "addslashes" czy "intval", to żadne "UNION" przemycone w treści nam nie zaszkodzi. Do tego właśnie zmierzało moje pytanie, na które do tej pory nikt nie odpowiedział jasno i wyraźnie: czy jeśli stosujemy odpowiednią filtrację danych (np. taką jak zaprezentowałem), to wstawienie przez użytkownika "UNION" w danych wejściowych może się źle skończyć? |
|
|
Wersja Lo-Fi | Aktualny czas: 24.09.2024 - 14:31 |