Pozwól mi zacząć od stwierdzenia, że jestem powiernikiem środków, które podjąłem, aby upewnić się, że ataki SQL Injection nie. Wszystkie wartości zapytań SQL są wykonywane za pomocą gotowych instrukcji przygotowanych rekordów, a wszystkie operatory, jeśli nie są zakodowane na sztywno, są wykonywane przez system białych list. To znaczy, że jeśli ktoś chce przeszukać za pomocą "ILIKE", przekażą 6, a jeśli będą chcieli wyszukiwać przez "=", to przekażą 1, itd.Regex wykrywa podstawowe iniekcje SQL, ale nie jako środek zapobiegający iniekcjom SQL
Używam też regularnie Brakeman i Rails SQL Injection guide do sprawdzania kodu.
Są trzy pozostałe powody, dla których chciałbym zablokować próbę wtryskiwaczy SQL.
- Dostajemy dużo skryptów, które próbują nas zhackować. Większość z nich to , które zostały już zablokowane co najmniej raz, ponieważ mamy rozszerzenie białej listy plików, które blokuje większość z nich, gdy próbują uzyskać dostęp do pliku php w postaci . Pewnego razu po raz pierwszy zostają na czarnej liście , w drugiej rundzie zwykle próbują rzucić nam książkę wtryskową SQL . Chciałbym więc oznaczyć te dzieciaki na początku do zaoszczędzić przepustowość, a jeśli prawdziwy aktor, który nas zaatakował, byłoby to łatwe do posortowania ich od wszystkich dzieci-skryptów.
- Spowolnij wszelkie próby zbadania naszej obrony. To naprawdę nie będzie skutkowało wyrafinowanymi, rozproszonymi atakami, ale może spowolnić działanie aktora, który jest gdzieś pomiędzy dzieckiem-skrypciarzem a super-hackerem.
- Zaznacz wszystkie zablokowane żądania i skonfiguruj powiadomienia o rejestrach, które my, , zostaną poinformowane przez naszą usługę rejestrowania, aby zwiększyć naszą świadomość w zakresie bezpieczeństwa .
W tej chwili moim pomysłem jest uruchomienie prostego regex mecz przeciwko ścieżce żądania, a parametry w celu flagą najbardziej rażące prób SQL injection i czarnej te adresy IP, więc coś takiego, używając rack-attack.
injection_regex = /SOMEREGEXHERE/
Rack::Attack.blacklist('sql injection blacklist') do |req|
Rack::Attack::Fail2Ban.filter(req.ip, :maxretry => 5, :findtime => 10.minutes, :bantime => 24.hours) do
CGI.unescape(req.query_string).match(injection_regex) || req.path.match(injection_regex)
end
end
Mój problem polega jednak na tworzeniu wyrażeń regularnych, które poprawnie oznaczają prostą próbę wstrzyknięcia SQL, ale nie powodują żadnych problemów dla zwykłych użytkowników. Uważam, że niektóre fałszywe alarmy są w porządku, i dlatego powyższy system czarnej listy nie jest czarną listą po pierwszym dopasowaniu.
W moich poszukiwaniach znalazłem wiele pytań na ten temat, ale wszystkie wydają się iść like this one, osoba zadaje pytania dotyczące korzystania z regex do wykrywania iniekcji SQL, inna osoba odpowiada, że nie powinnaś zatrzymywać SQL injection w ten sposób , osoba, która zadała pytania, odpowiada, że nie użyłby wyrażenia regularnego, aby przestać, ale tylko do wykrycia, a następnie kilka niezbyt użytecznych komentarzy.
Czy istnieje więc możliwość, że takie wyrażenie działa tylko w celu wykrycia, z minimalnymi fałszywymi trafieniami, czy też jest to taki cały królik, że nie byłoby to warte wysiłku?
Jestem pewien, że to możliwe, do pewnego stopnia. Jednak miejscem, od którego należy zacząć, jest zebranie listy rzeczy, które chcesz wyszukać. Po uzyskaniu tej listy możesz pracować nad utworzeniem wzorca, aby je znaleźć. –
Czy spojrzał [to] (http://www.symantec.com/connect/articles/detection-sql-injection-and-cross-site-scripting-attacks)? Jednym z rozwiązań problemu może być tworzenie kilku poziomów z tymi wyrażeniami regularnymi, w których dane wejściowe są przekazywane. Jeśli jakikolwiek poziom odpowiada temu ostrzeżeniu. –