Czy powinienem martwić się zastrzykiem PHP, jeśli nie używam MySQL?

Question

Używam prostego skryptu PHP do uruchomienia komiksu online, który w zasadzie używa GET, aby pobrać wartość całkowitą n i wstawić znacznik img dla n .jpg. Nie przeprowadza żadnych prób odkażania ani sprawdzania błędów poza upewnieniem się, że istnieje n .jpg. Jedyną interakcją użytkownika ze skryptem jest ten GET, a drugi robi to samo z ciągiem, aby ręcznie wyświetlać inny szablon do testowania.

Moje pytanie brzmi, czy powinienem się martwić o zastrzyk? A jeśli tak, to co powinienem zrobić, aby temu zapobiec? Wszystko, co znalazłem do tej pory dotyczy tylko wstrzyknięcia MySQL, co nie ma zastosowania w tym przypadku.

Answer 1

Jeśli nie korzystasz z bazy danych, wtedy oczywiście SQL injection nie jest dla ciebie problemem. Podobnie, jeśli nie przechowujesz żadnych danych przesłanych przez użytkowników, aby wyświetlić je innym użytkownikom, nie jest to problemem. Pozostawia to takie rzeczy jak eval() lub uruchamianie zewnętrznych procesów, które atakujący może przekreślić, ale nie brzmi to tak, jakbyś zrobił coś takiego.

Więc prawdopodobnie jesteś bezpieczny. Mimo to dobrze byłoby mieć minimalną ilość sprawdzania błędów, aby tylko wejść w nawyk. Na przykład mówisz, że masz liczbę całkowitą GET. Nie ma czegoś takiego - wszystkie parametry HTTP są ciągami implicit. PHP rozmywa to rozróżnienie, ale zdecydowanie powinieneś rzucić je do int jawnie, aby upewnić się, że nie jest to jakiś ciąg mający wykorzystać lukę XSS, SQL injection lub eval (nawet jeśli żadna taka nie istnieje).

Answer 2

Powinieneś zawsze martwić się bezpieczeństwem. Nie każda dziura bezpieczeństwa składa się przez niewłaściwym wykorzystaniem mysql :-)

Answer 3

Jeśli get ma zawierać jedynie korzystanie całkowitą

$n = intval($_GET['n'])

Answer 4

Zastrzyk SQL nie ma zastosowania w przypadku, ponieważ ciebie nie korzystają z bazy danych dla Twojej witryny. Ale powinieneś rozważyć inne problemy z bezpieczeństwem dla swojej strony, takie jak cross site scripting.

Jeśli używasz zmiennej z GET, należy rozważyć poniżej URL:

index.php?myvar=<script>alert(document.cookie);</script> 

Hakerzy są w stanie dostarczyć wyżej adres URL w hex numer sposoby, UTF itd

Zły facet może zmodyfikuj zmienne GET, aby wykonać ataki XSS. XSS jest źródłem wielu luk w zabezpieczeniach. Musisz to również wziąć pod uwagę.

Jeśli spodziewasz typ numeryczny z Twojego GET var następnie rozważyć poniżej kod:

$myvar = (int) $_GET['your_var']; 

Należy użyć htmlentities funkcję, aby zapobiec atakom XSS.

Answer 5

Allways sprawdza dane wprowadzane przez użytkownika oraz dane $ _GET i $ _POST w poszukiwaniu szkodliwej zawartości. Addslashes, ereg_match i intval są twoim przyjacielem ...

Jeśli można uciec z nim, ustawić dyrektywę

allow_url_fopen = Off 

w php.ini

Answer 6

Jeśli spodziewasz się numeru, nie odkażaj złych danych wejściowych, odmawiaj.

if (!ctype_digit($user_input)) { 
    header('Location: error.php'); // or whatever page 
    exit; 
} 

Answer 7

ja również zwraca hit żądany katalog zdjęć też, jak nie chcą ludzie przeglądania serwer plików wniosków jak example.com/?q=../../.htaccess

Nie jestem pewien, jak to wpłynie na wyjście, ale to nie może być dobre.

Answer 8

Nie musisz się martwić o wstrzyknięcie SQL. Ale powinieneś sprawdzić dane wejściowe, jakie są używane w generowanym html. Wyobraź sobie, że daję komuś ten link: http://www.example.com/viewComic.php?id="/><script type="text/javascript>alert("XSS");</script><img src="22. Ta osoba będzie miała małe okienko wyskakujące z Twojej witryny. A wiele złych rzeczy można zrobić za pomocą javascript. Aby uzyskać więcej informacji, możesz rozpocząć czytanie strony wikipedii o numerze: XSS.

Należy więc sprawdzić, czy liczba, której oczekujesz, jest liczbą. Na przykład z is_numeric.