Nie poświęcaj dużo czasu na obejścia lub połowiczne poprawki. Każda minuta spędzona na próbach implementacji czegokolwiek, co tu sugeruje, to minuta, którą mógłbyś poświęcić na wdrażanie przygotowanych wypowiedzi. To jedyne prawdziwe rozwiązanie.

Jeśli masz lukę w zabezpieczeniach SQLi, atakujący prawdopodobnie w końcu wygra, bez względu na to, co zrobisz, aby ją spowolnić. Więc pamiętaj, że chociaż możesz wprowadzać ulepszenia, w końcu grasz przegraną, chyba że naprawisz główną przyczynę problemu.

Co do tego, co próbowałeś do tej pory: ukrywanie komunikatów o błędach Dobry początek. Zalecałbym zastosowanie jeszcze surowszych uprawnień (patrz poniżej). Jest dyskusyjne, czy zmiana nazw tabel pomoże, ale prawdopodobnie nie zaszkodzi.

Ok, a co z tymi uprawnieniami? Ogranicz możliwości użytkownika bazy danych tak bardzo, jak to możliwe, do poziomu tabeli lub nawet kolumny. Możesz nawet utworzyć wielu użytkowników bazy danych, aby jeszcze bardziej blokować rzeczy. Na przykład, używaj tylko użytkownika bazy danych z uprawnieniem do pisania, kiedy faktycznie piszesz. Łącz się tylko z użytkownikiem, który ma prawo odczytać kolumnę z hasłem, gdy faktycznie musisz przeczytać kolumnę hasła. W ten sposób, jeśli masz lukę umożliwiającą wstrzyknięcie w jakimś innym zapytaniu, nie można jej wykorzystać do wycieku haseł.

Inną opcją jest użycie zapory aplikacji internetowej (WAF), takiej jak mod_security dla Apache. Możesz go skonfigurować tak, aby blokował żądania, które wyglądają podejrzanie. Jednak żaden WAF nie jest doskonały. Konfiguracja wymaga czasu i energii. Prawdopodobnie lepiej wykorzystasz ten czas na implementację przygotowanych oświadczeń.

Ponownie, nie pozwól, aby cokolwiek z tego zwabiło Cię w fałszywe poczucie bezpieczeństwa. Nic nie zastąpi naprawienia głównej przyczyny problemu.

Jedynym poprawnym sposobem jest użycie przygotowanych instrukcji.

1. Jeśli ukryjesz komunikaty o błędach, jest to nieco trudniejsze, ale nie powstrzyma to atakujących.
2. Możesz ograniczyć prawa, ale wszystkie prawa przyznane użytkownikowi mogą uzyskać osoba atakująca. W niektórych przypadkach możliwe jest również wykonanie poleceń powłoki z SQL-Injection.
3. Zmiana nazw tabel nie pomoże. Narzędzie sqlmap będzie brutalnie wymuszać nazwy tabel dla Ciebie char po znaku. To nie wymaga dużo czasu.

Możesz również ograniczyć liczbę połączeń, aby utrudnić atakującym lub włączyć alerty o podejrzanych połączeniach i zatrzymać tę instrukcję, ale jedynym poprawnym sposobem rozwiązania tego problemu jest użycie przygotowanych instrukcji. Po prostu przejrzyj kod źródłowy i spójrz na instrukcje SQL z dynamiczną zawartością i zamień je.

Wiemy, ale nie mamy wystarczającej liczby programistów / testerów, aby zapewnić 100% bezpieczeństwo.

To jest prawdziwy problem . Dopóki nie zatrudnisz większej liczby osób lub nie zmienisz priorytetów, nie jesteś bezpieczny. Zatrzymanie 99,9% napastników oznacza, że ​​Twoje dane zostały naruszone. Rozwiązania pomocnicze są złe i nie działają . Nie trać czasu na refaktoryzację wzorca dostępu SQL, podczas gdy możesz naprawiać rzeczywiste problemy.

Jeśli chodzi o rozwiązanie kodu, użycie przygotowanych instrukcji, jak sugeruje wiele osób, jest najłatwiejszym sposobem bezpiecznego korzystania z SQL.

Jest to o wiele łatwiejsze niż próba użycia php do samodzielnego czyszczenia argumentów i kosztuje o wiele mniej czasu. Po prostu przeszukaj całą bazę kodu dla wszystkiego, co dotyczy SQL, i napraw to.

Usuń na zawsze cały kod SQL z kodu

Najlepszym rozwiązaniem tego problemu jest usunięcie całego kodu SQL w postaci ciągów literałów z kodu i nigdy więcej nie wprowadzaj go. Zamiast tego użyj oprogramowania ORM, takiego jak Hibernate lub Entity Framework. To oprogramowanie jest i tak o wiele przyjemniejsze w użyciu niż surowy SQL i automatycznie parametryzuje SQL, gdy ostatecznie trafia do bazy danych. Jeśli to możliwe, miej tę politykę.

Jeśli nie masz czasu na naukę i implementację tych pakietów lub nie możesz ich użyć z innego powodu, odpowiedź trietendy jest następną najlepszą rzeczą, używając przygotowane oświadczenia. Pozwoli to zabezpieczyć się przed iniekcją SQL. Oznacza to, że dopóki nie wywiążesz presji na programistów, aby dostarczali szybkie rozwiązania, wtedy mogą ponownie zapomnieć o parametryzacji jednej zmiennej, pozostawiając Cię z powrotem tam, gdzie zacząłeś.

Wiemy, ale nie mamy wystarczającej liczby programistów / testerów, aby uczynić go w 100% bezpiecznym.

Nie jest do końca jasne, co masz na myśli przez to oświadczenie, ponieważ zostało przygotowane instrukcje są trywialne w każdym popularnym języku sieciowym (PHP, Python, Java, node.js itp.) i są mniej więcej w 100% skutecznym środkiem przeciwko iniekcji SQL.

Czy masz na myśli podzlecanie i nie możesz sobie pozwolić na kontrolę jakości kodu, który piszą dla Ciebie na podstawie umowy? Nie możesz sobie pozwolić, aby tego nie robić: nadal jesteś tutaj odpowiedzialną stroną.

Czy masz na myśli, że twoi programiści są zbyt zajęci wdrażaniem funkcji, aby aktualizacja kodu źródłowego zajęła kilka godzin? Wszystko inne niż przygotowane oświadczenia zajmie więcej czasu i będzie kosztować więcej (np. ORM, zaciemnianie, szczegółowe uprawnienia itp.).

Czy masz na myśli, że twoi programiści nie są wystarczająco kompetentni, aby wykonać to proste zadanie? To chyba większy problem (a ściślej mówiąc, wstrzyknięcie SQL nie powinno być Twoim największym zmartwieniem w tym momencie).

Czy masz na myśli, że twoją bazą kodową jest taki spaghetti-logiczny bałagan w formacie shotgun z zagnieżdżonymi include s, których wykonanie nawet kompetentnym programistom zajmie wieczność, co w innym przypadku byłoby prostym zadaniem trwającym kilka godzin? Podobnie, większy problem.

Ktokolwiek to jest, rozwiązaniem jest użycie przygotowanych wyciągów, około wczoraj.

Po wdrożeniu wstępnej porady dotyczącej "przygotowanej instrukcji", polecam poczytać o wstrzykiwaniu SQL. Pytanie „jak zapobiec iniekcji SQL” to dość szerokie pytanie! Bezpieczeństwo to temat, z którym Ty (a raczej cały Twój zespół programistów) musicie się bardzo dobrze zapoznać, aby zmniejszyć ryzyko kompromisu. Jedna dziura podważa wszystkie twoje inne wysiłki.

Odwiedź Open Web Application Security Project (OWASP) tutaj: https://www.owasp.org/index.php/SQL_Injection

W szczególności materiał dodatkowy:

• Ściągawka dotycząca zapobiegania iniekcjom SQL
• Ściągawka dotycząca parametryzacji zapytań
• Artykuł przewodnika na temat unikania luk w zabezpieczeniach związanych z iniekcją SQL

A także

• Jak przejrzeć kod pod kątem luk w zabezpieczeniach związanych z iniekcją SQL .

Rozwiązaniem tymczasowym byłoby przyjrzenie się zaporze aplikacji internetowej (WAF) - jest kilka firm, które zapewniają to jako usługę, i kilku dostawców chmury, którzy również mają swoje oferty. Wydaje się, że CloudFlare oferuje jeden, miałem jednego klienta używającego Incapsula i wiem, że oferta AWS WAF ma kilka zarządzanych zestawów reguł do wstrzykiwania SQL.

Sposób, w jaki to działa, polega na tym, że cały ruch jest wysyłany do / przez WAF (albo przez włączenie go na serwerach, albo ustawienie DNS tak, aby wskazywał na WAF, tak jak w przypadku CDN) i szuka rzeczy które wyglądają jak próby wstrzyknięcia SQL w parametrach. Nie przechwytuje wszystkich ataków i może blokować legalny ruch, ale jest to dostępna poprawka.

Rozumiem, że przez „nie ma wystarczającej liczby programistów” masz na myśli, że niektórzy wpływowi ludzie w Twojej organizacji uważają, że istnieją wyższe priorytety, więc wszelkie zasoby, które masz, są przeznaczone na te rzeczy. Zatem naprawienie problemu z bezpieczeństwem jest przegraną na rzecz innych rzeczy w analizie kosztów i korzyści.

Twoim zadaniem jest tutaj zmiana zdania, tak samo jak wdrożenie poprawki. Określ ilościowo, o co toczy się gra - jaka byłaby szkoda, zarówno pod względem finansowym, jak i reputacyjnym, w przypadku kolejnego naruszenia? W Twojej jurysdykcji mogą obowiązywać przepisy, które wymagają zgłaszania naruszeń danych użytkownika. Czy to byłoby żenujące? Czy media mogą donosić o złych praktykach Twojej organizacji?

Pomyśl o inwestycji polegającej na naprawie zabezpieczeń jako o ubezpieczeniu. Z perspektywy czasu, gdy wiesz, że Twój budynek nie spłonął przez okres dziesięciu lat, możesz argumentować, że Twoje składki były stratą. Ale Ty i Twoja organizacja płacicie za ubezpieczenie, ponieważ czeka was niepewna przyszłość. To zarządzanie ryzykiem.

Ryzyko ma dwa czynniki: prawdopodobieństwo i wpływ. Prawdopodobieństwo kolejnego naruszenia jest wysokie - wiesz, że może i zostało zrobione przynajmniej raz. Jeśli potencjalne konsekwencje są również złe, powinieneś zwiększyć priorytet naprawy swoich luk w zabezpieczeniach.

Jak wszyscy wspominali, napraw kod na stronie.

Możesz zrobić dowolne łaty na ścianie, ale dopóki ściana nie zostanie poprawnie zbudowana, wszelkie łaty będą stanowić przeszkodę dla problemu krwawienia.

Każda inna sugestia dotycząca czyszczenia kodu jest tym, co Linus Torvalds nazwałby masterbation.

• Napraw kod (z najbardziej oczywistych punktów wtrysku do ostatnich parametrów IE Get) i użyj przygotowanych instrukcji. jak mogę zapobiec iniekcji sql w php

  • Możesz wypróbować WAF (IE ModSecurity ) tymczasowo, dopóki nie będziesz w stanie naprawić.

  • Spróbuj Być może jakiś rodzaj blokady adresu IP dla „osób testujących witrynę” lub blokujących wykonywanie niebezpiecznych zapytań.

  • Jeśli masz możliwość utworzenia tymczasowego (bezpiecznego) ekranu logowania z przodu, dopóki ten problem nie zostanie rozwiązany.

  • Wypróbuj usługę innej firmy, dopóki problem nie zostanie rozwiązany, na przykład Cloudflare lub cokolwiek innego tam.

PDO są dostępne od PHP 5.1 wypuszczonego 24 listopada 2005 ... Twórcy muszą zrozumieć, że mają one konsekwencje ich kiepskie nawyki w zakresie kodowania i osobiście uważam, że za jakość wykonywanej pracy należy odpowiadać.

W każdym razie PDO są łatwe do wdrożenia. Jeśli twoi programiści nie są w stanie zapewnić lepszej jakości, sugerowałbym czyszczenie ...

Najważniejsza zasada to:

Używaj bibliotek, narzędzi i interfejsów API, które sprawiają, że opcja bezpieczna jest najłatwiejsza.

Nacht mówi „po prostu użyj ORM ”, który jest podzbiorem tej reguły.

Gotowe instrukcje naruszają tę zasadę, ponieważ są niewygodne w użyciu, powodują rozdęcie kodu, a także często mogą być wolniejsze niż instrukcje nieprzygotowane, w zależności od Baza danych. Są dobrym rozwiązaniem, nie będę krytykować nikogo, kto ich używa, ale niekoniecznie są one najlepszym i najwygodniejszym rozwiązaniem.

I ... chcemy, aby opcja bezpieczna była łatwa i wygodna, dlatego programista używa go dla własnego interesu i lenistwa. Chcemy, aby programista musiał zejść mu z drogi i włożyć trochę wysiłku, aby użyć niebezpiecznej opcji! ...

O wiele lepszym rozwiązaniem jest API, takie jak Python dbapi. Napisałem odpowiednik php lata temu, który wyglądał tak:

  db_query ("SELECT * FROM mytable WHERE id =% s", $ id)  

Jest to wygodniejsze niż przygotowane oświadczenia. Tylko jeden wiersz do wpisania. Zwraca również wynik w postaci, której może używać foreach (), więc jest dużo łatwiejszy w użyciu niż fetch () i takie tam. Co ważniejsze, kod ukryty za tym interfejsem API będzie poprawnie obsługiwał ucieczkę. To sprawia, że ​​iniekcje SQL są nieistotne. Obsługuje około 99% zapytań, jeśli nie używasz ORM. Dynamiczne zapytania (zwykle wyszukiwanie) będą jednak wymagały specjalnej obsługi, ale nadal jest to łatwe.

Jeśli będziesz pamiętać o tej zasadzie, w pewnym momencie będziesz musiał się zastanawiać, dlaczego musisz używać htmlspecialchars (), i dlaczego język nie ma funkcji, która sprawiłaby, że ustawienie bezpieczne (tj. brak wulgaryzmów XSS) byłoby najłatwiejsze w użyciu? Dlaczego oh dlaczego? I wtedy upuszczasz PHP.

Oprócz wszystkich świetnych dotychczas odpowiedzi, jeśli chcesz rozwiązać specyficzny problem z wyodrębnianiem danych logowania użytkownika, możesz zmienić swoją bazę danych tak, aby hasła znajdowały się w osobnej tabeli ze ścisłymi prawami dostępu , podobnie do sposobu, w jaki systemy uniksowe umieszczają je w /etc/shadow.

Aby zweryfikować poświadczenia, potrzebujesz procedury składowanej, która przyjmuje wprowadzone hasło (lub hash) jako parametr i zwraca wartość logiczną. Innymi słowy, odciążasz zadanie weryfikacji poświadczeń w bazie danych, a rzeczywisty hash nigdy nie opuszcza bazy danych.

Wymaga to minimalnej refaktoryzacji i rozwiązuje natychmiastowy problem u źródła, zamiast jednego konkretnego wstrzyknięcia SQL, podczas gdy pozostawiając cię bezbronnym na następny.