SQL Injection/Insertion, Jak zapobiec włamaniu na stronę. |
SQL Injection/Insertion, Jak zapobiec włamaniu na stronę. |
4.03.2013, 13:28:50
Post
#401
|
|
Grupa: Zarejestrowani Postów: 273 Pomógł: 52 Dołączył: 3.02.2013 Skąd: Przemyśl Ostrzeżenie: (0%) |
Puszczenie całego zapytania przez mysql_real_escape_string "zniszczy" go, przykładowo:
Przed:
Po: Po użyciu mysql_real_escape_string:
Kolega wyżej dobrze radzi, tym bardziej że aktualnie funkcje mysql_ są już deprecated -------------------- Jeżeli moja wypowiedź Ci pomogła użyj przycisku
|
|
|
14.03.2013, 01:37:31
Post
#402
|
|
Grupa: Zarejestrowani Postów: 227 Pomógł: 0 Dołączył: 13.06.2003 Skąd: rykowice Ostrzeżenie: (0%) |
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? o ile dobrze pamiętam to podstawówkę zaczyna się właśnie od... intval, a mysql_real_escape_string() raczej wpływ na szeroko pojętą kompatybilność niż zabezpieczanie przez atakami. 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. 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) No i ja się dołączam do pytania, nie wiem po co zabezpieczać dane które wyświetlam więc tu proszę o jakieś uzasadnienie. Zawsze wydawało mi się że najważniejsze są dane wprowadzane do bazy czy też odbierane od użytkownika. Zwalanie wszystkie na PDO raczej nie załatwia tematu i nie zabezpiecza z samego tytułu jego używania. Inni może wolą inne rozwiązania albo chcą po prostu wiedzieć. Ten post edytował Gligamesh 14.03.2013, 01:38:57 |
|
|
14.03.2013, 07:19:00
Post
#403
|
|
Grupa: Moderatorzy Postów: 36 447 Pomógł: 6292 Dołączył: 27.12.2004 |
Do bazy jak wkładasz to zabezpieczeasz przed sqlinjection.
Podczas wyświetlania zaś bronisz się np. przed XSS. Dlatego do bazy nie wkłada się danych przepuszczanych przez htmlspecialchars. Tę funkcję używa się dopiero przed wyświetlaniem -------------------- "Myśl, myśl, myśl..." - Kubuś Puchatek || "Manual, manual, manual..." - Kubuś Programista "Szukaj, szukaj, szukaj..." - Kubuś Odkrywca || "Debuguj, debuguj, debuguj..." - Kubuś Developer |
|
|
14.03.2013, 11:00:02
Post
#404
|
|
Grupa: Zarejestrowani Postów: 227 Pomógł: 0 Dołączył: 13.06.2003 Skąd: rykowice Ostrzeżenie: (0%) |
Podczas wyświetlania zaś bronisz się np. przed XSS. Dlatego do bazy nie wkłada się danych przepuszczanych przez htmlspecialchars. Tę funkcję używa się dopiero przed wyświetlaniem Nie znam się za bardzo na atakach (inaczej bym pewno nie pytał) ale irracjonalne jest trochę filtrowanie danych wyświetlanych. Z prostej przyczyny są tylko wyświetlane i nigdzie nie są zapisywane. Z tego co przeczytałem o XSS to też biega o zapis... |
|
|
14.03.2013, 11:22:09
Post
#405
|
|
Grupa: Moderatorzy Postów: 36 447 Pomógł: 6292 Dołączył: 27.12.2004 |
1) Proszę nie mieszaj już w tym wątku o XSS. To jest wątek o SQLInjection
2) I tak i nie. Owszem, trzeba filtrować np. komentarz by ktoś nie zrobił ataku xss, ale to nie polega na htmlspiecialchars do wkladania do bazy. A htmlspecialchars przed wyswietleniem używa się profilaktycznie, jakbyś źle dofiltrował dane od usera. Ale koniec już na ten temat w tym wątku -------------------- "Myśl, myśl, myśl..." - Kubuś Puchatek || "Manual, manual, manual..." - Kubuś Programista "Szukaj, szukaj, szukaj..." - Kubuś Odkrywca || "Debuguj, debuguj, debuguj..." - Kubuś Developer |
|
|
20.06.2013, 00:15:28
Post
#406
|
|
Grupa: Zarejestrowani Postów: 2 355 Pomógł: 533 Dołączył: 15.01.2010 Skąd: Bydgoszcz Ostrzeżenie: (0%) |
Da się jakoś w postgresql wydobyć wszystkie nazwy kolumn w danej tabeli? O ile w MySQL mamy podatność sql injection, to nie jest to żaden problem, o tyle w postgresql tabele jeszcze można przejrzeć, ale już z nazwami kolumn lipa. Żadnego information_schema ni widu, ni słychu ;/
|
|
|
20.06.2013, 12:34:59
Post
#407
|
|
Grupa: Moderatorzy Postów: 15 467 Pomógł: 1451 Dołączył: 25.04.2005 Skąd: Szczebrzeszyn/Rzeszów |
-------------------- ZCE :: Pisząc PW załączaj LINK DO TEMATU i TYLKO w sprawach moderacji :: jakiś błąd - a TREŚĆ BŁĘDU? :: nie ponaglaj z odpowiedzią via PW! |
|
|
2.07.2013, 08:29:22
Post
#408
|
|
Grupa: Zarejestrowani Postów: 251 Pomógł: 23 Dołączył: 23.04.2013 Ostrzeżenie: (0%) |
Kolega wyżej dobrze radzi, tym bardziej że aktualnie funkcje mysql_ są już deprecated Co do MySQL... Sterownik mysql już w roku 2009 był uważany za "powrót do przeszłości". Jeśli chodzi o silnik MySQL, to SQL Injection jest raczej problemem dla żółtodziobów, którzy uczą się PHP oraz MySQL z samouczków napisanych w czasach, kiedy na Ziemi ludzie żyli z dinozaurami (okazuje się, że znaleziono kilkukrotnie ludzkie szczątki obok szczątek dinozaurów). Wiadomo, że programista z powołania szybko dojdzie do tego, że mysql to już staroć (wystarczy pierwsza lepsza aktualna książka), ale młokosi będą się męczyć z tutorialami i problemami, które już dawno zostały rozwiązane. A z tego powodu, że młokosami i klepaczami kodu nikt się nie martwi, to będą dalej trwać w Ciemnogrodzie i nikt ich za szybko o niczym nie uświadomi - choć z drugiej strony to dobrze, bo wcześniej przejdą selekcję przydatności do zawodu. *wink* W końcu jeśli ktoś w tym fachu nie potrafi samemu zadbać o to, aby wiedzieć co jest up-to-date, wtedy będzie z niego dupa a nie programista. |
|
|
6.10.2013, 08:57:03
Post
#409
|
|
Grupa: Zarejestrowani Postów: 2 148 Pomógł: 230 Dołączył: 26.03.2008 Ostrzeżenie: (0%) |
@Dejmien_85, gadasz o młokosach, a sam z siebie jednego zrobiłeś.
Tak czy inaczej pozdrawiam. -------------------- ET LINGUA EIUS LOQUETUR IUDICIUM
|
|
|
16.10.2013, 19:29:18
Post
#410
|
|
Grupa: Zarejestrowani Postów: 251 Pomógł: 23 Dołączył: 23.04.2013 Ostrzeżenie: (0%) |
@pyro, nie wnikam w Twoje prywatne wierzenia. Skoro zaprzeczasz temu, że pewne problemy rozszerzenia mysql zostały rozwiązane przez jego następców (mysqli, PDO) i dodatkowo nazywasz mnie młokosem za takie stwierdzenie, wtedy ofiarować mogę Tobie jedynie krzyrzyk na drogę.
Problem SQL Injection jest mocno zredukowany, gdy używa się mysqli/PDO, ejmen. Ten post edytował Dejmien_85 16.10.2013, 19:40:00 |
|
|
18.10.2013, 14:50:07
Post
#411
|
|
Grupa: Zarejestrowani Postów: 2 148 Pomógł: 230 Dołączył: 26.03.2008 Ostrzeżenie: (0%) |
@pyro, nie wnikam w Twoje prywatne wierzenia. Skoro zaprzeczasz temu, że pewne problemy rozszerzenia mysql zostały rozwiązane przez jego następców (mysqli, PDO) i dodatkowo nazywasz mnie młokosem za takie stwierdzenie, wtedy ofiarować mogę Tobie jedynie krzyrzyk na drogę. Problem SQL Injection jest mocno zredukowany, gdy używa się mysqli/PDO, ejmen. Powiem Ci jedynie tak: Istnieje mnóstwo podatnych na SQL Injection skryptów, mimo że używają wyłącznie mysqli / PDO. Z tydzień temu znalazłem nawet w [ciach, może jednak lepiej nie mówić], najnowszej wersji, gdzie nie ma ani jednego użycia sterownika mysql i na pierwszy rzut oka tego nie widać. Nawet przy ORMach też się można włamywać, bo czasem trzeba użyć Native Query przy bardzo skomplikowanych zapytaniach. i dodatkowo nazywasz mnie młokosem Nawet nie użyłem tego słowa, sam zacząłeś . Ten post edytował pyro 18.10.2013, 15:54:00 -------------------- ET LINGUA EIUS LOQUETUR IUDICIUM
|
|
|
18.10.2013, 15:49:28
Post
#412
|
|
Grupa: Nieautoryzowani Postów: 2 249 Pomógł: 305 Dołączył: 2.10.2006 Ostrzeżenie: (0%) |
Problem SQL Injection jest mocno zredukowany, gdy używa się mysqli/PDO, ejmen. To nie jest remedium na całe zło, liczy się myśląca głowa przede wszystkim. Zauważ też, że ryzyko zredukowane nie oznacza, że go nie ma. -------------------- Google knows the answer...
|
|
|
18.10.2013, 16:00:28
Post
#413
|
|
Grupa: Zarejestrowani Postów: 3 033 Pomógł: 366 Dołączył: 24.05.2012 Ostrzeżenie: (0%) |
pedro84 dokładnie, ale jak widać niektórym się wydaje, że jak użyją PDO/mysqli to już o nic się nie muszą wgl martwić.
Dejmien_85 To wszytko zależy od tego jak to oprogramujemy, owszem PDO może ten proces ułatwia, ale już nie raz ludzie przychodzili tu na forum i dawali do oceny strony gdzie na starcie było SQL Injection mimo iż wcale nie używali mysql_* Ten post edytował com 18.10.2013, 16:01:34 |
|
|
21.10.2013, 12:12:20
Post
#414
|
|
Grupa: Zarejestrowani Postów: 251 Pomógł: 23 Dołączył: 23.04.2013 Ostrzeżenie: (0%) |
Panowie, spokojnie, nikt tutaj nie chce nikomu krzywdy zrobić. ; )
Problem SQL Injection oczywiście istnieje i zawsze będzie istniał, jednak przy użyciu sterowników mysqli czy PDO podchodzi się do niego inaczej - aplikację jest po prostu łatwiej i szybciej zabezpieczyć. Oczywiście nie ma problemu, aby bazę danych dobrze zabezpieczyć przy korzystaniu z DB z użyciem rozszerzenia mysql, jednak pojawia się pytanie: "Czemu mam jeździć starym autem, skoro w garażu stoi nowe?". Nie będę także zaprzeczał starego powiedzenia: "o gustach się nie dyskutuje". Jedni wolą nowe auta, inni stare. W sumie ich działanie jest podobne - auto ma dojechać do punktu B z punktu A. Wszystkie rozszerzenia jadą, tylko troszkę inaczej. Wybierajmy swoje typy, cieszy się jazdą - w końcu o to chodzi. Ale weźmy także pod uwagę to, że w świecie IT wszystko idzie do przodu i to co dzisiaj jest na topie za kilka lat zostanie czymś zastąpione. Nieustanny rozwój czasem jest męczący - jednak w przypadku naszej branży niestety jest konieczny. Uczmy się, wyciągajmy wnioski, żyjmy w zgodzie - peace and love. Na zakończenie jeszcze zapraszam wszystkich na koncert słitaśnej muzyki, niech nas pogodzi! http://www.youtube.com/embed/0gEVaniPOmU?rel=0 Przysięgam, że dużo nie piłem. Ten post edytował Dejmien_85 21.10.2013, 12:13:25 |
|
|
21.10.2013, 13:49:07
Post
#415
|
|
Grupa: Zarejestrowani Postów: 2 148 Pomógł: 230 Dołączył: 26.03.2008 Ostrzeżenie: (0%) |
Tu nie chodzi o gusta, bo sterownik mysql to jest przeżytek bez wątpienia. Chodzi o to, że z punktu widzenia SQL Injection np. PDO jest taką samą gwarancją bezpieczeństwa jak jogurt naturalny jest gwarancją zwycięzkich walk wojowniczki Xeny. -------------------- ET LINGUA EIUS LOQUETUR IUDICIUM
|
|
|
21.10.2013, 18:11:53
Post
#416
|
|
Grupa: Zarejestrowani Postów: 251 Pomógł: 23 Dołączył: 23.04.2013 Ostrzeżenie: (0%) |
Pyro, Ty nam tutaj Xeny nie mieszaj do SQL Injection.
Wszystko zostało już powiedziane: 1) Stopień zabezpieczenia zależy od programisty - dokładnie jego wiedzy i stopnia lenistwa (nie od sterownika). 2) PDO/mysqli niweluje pewne ataki (jednak ich nie eliminuje w 100%). Użycie PDO/mysqli powoduje, że pewne rzeczy mamy z głowy (ex-problemy mysql) i nie musimy się nimi przejmować (i to napisałem gdzieś tam wyżej w pierwszym poście). Także proponuję zakończyć ten temat przy zimnym browarku (póki jeszcze ciepło jest). No chyba, że się zbroisz, wtedy... |
|
|
21.10.2013, 18:16:36
Post
#417
|
|
Grupa: Moderatorzy Postów: 36 447 Pomógł: 6292 Dołączył: 27.12.2004 |
@Dejmien, dla Pyro chodzi zapewne o to, ze ktos moze uzywac PDO ale zapytania pisac normalnie, bez bindowania wartosci. Wowczas te PDO na nic sie zdaje. A uwierz, tu na forum była cała masa osob, ktore tak wlasnie robily. Niektore nawet sprzedawaly swoje skrypty jako super hiper a w kodzie kwiatki takie kwiatki:
$pdo->query("select ..... from...... where pole='{$_POST['zmiennazforma']}' "); Wiec podsumujmy: tak, PDO rozwiazuje zdecydowanie wiekszosc problemow ale pod warunkiem, ze wiemy jak z niego korzystac. Bo samo jego zastosowanie a robienie rzeczy jak kod powyzej, da nam gu......zik -------------------- "Myśl, myśl, myśl..." - Kubuś Puchatek || "Manual, manual, manual..." - Kubuś Programista "Szukaj, szukaj, szukaj..." - Kubuś Odkrywca || "Debuguj, debuguj, debuguj..." - Kubuś Developer |
|
|
21.10.2013, 18:25:42
Post
#418
|
|
Grupa: Nieautoryzowani Postów: 2 249 Pomógł: 305 Dołączył: 2.10.2006 Ostrzeżenie: (0%) |
Wszystko zostało już powiedziane: 1) Stopień zabezpieczenia zależy od programisty - dokładnie jego wiedzy i stopnia lenistwa (nie od sterownika). 2) PDO/mysqli niweluje pewne ataki (jednak ich nie eliminuje w 100%). Niweluje? Dobre żarty. Wystarczy jeden klepacz, który nie użyje parametryzowanego zapytania i cała Twoja teoria leży. PDO jest wygodniejsze, nowocześniejsze i powinno się go używać już na samym początku, ale pisanie, że samo użycie PDO rozwiązuje problem wstrzyknięć jest sporą bzdurą. PS. Poczytaj: http://stackoverflow.com/questions/134099/...t-sql-injection Ten post edytował pedro84 21.10.2013, 18:26:06 -------------------- Google knows the answer...
|
|
|
21.10.2013, 19:27:03
Post
#419
|
|
Grupa: Zarejestrowani Postów: 251 Pomógł: 23 Dołączył: 23.04.2013 Ostrzeżenie: (0%) |
Wystarczy jeden klepacz, który nie użyje parametryzowanego zapytania i cała Twoja teoria leży. Ech, posiadam chyba zbyt wielką wiarę w ludzi. Gdy wsiadam do auta, to zawsze zapinam pasy - niektórzy jednak widzą w nich tylko kawałek wiszącego materiału, albo w ogóle ich nie zauważają. Rozsądny programista wie do czego służy PDO i tego się trzymam. Ale rację macie, czasem trzeba wytknąć rzeczy oczywiste - dla niektórych ludzi nie są one tak oczywiste. Z tego też powodu moje wcześniejsze wypowiedzi należy zmodyfikować - PDO/mysqli niwelują... jednak póki są odpowiednio wykorzystane. Poza tym, chyba wiem w czym problem - w dziale książek ktoś kiedyś napisał, że nie warto czytać książek, ponieważ wszystko można znaleźć w internecie - i tu się zaczynają problemy. Ten post edytował Dejmien_85 21.10.2013, 19:28:29 |
|
|
13.12.2013, 16:27:46
Post
#420
|
|
Grupa: Zarejestrowani Postów: 15 Pomógł: 0 Dołączył: 10.04.2012 Ostrzeżenie: (0%) |
1. Aby się zabezpieczyć na 100% przed usunięciem tabeli najlpeszym rozwiązaniem jest dodanie nowego użytkownika z ograniczonymi uprawnieniami globalnymi.
2. Zaminast dokładać linijek kodu PHP aby przefiltować GET można użyć htaccess, wtajemniczeni wiedzą, że oprócz przyjaznych linków ( np. zamiast ?user=12 można zrobić user-12 ) istnieje możliwość przefiltrowania tekstu np. tylko liczby, tylko duże litery, itp. |
|
|
Wersja Lo-Fi | Aktualny czas: 19.04.2024 - 23:50 |