Forum PHP.pl

Witam.

Chciałbym rozpocząć temat o bezpieczeństwie skryptów php. Na forum istnieje już temat o bezpieczeństwu przy wykonywaniu zapytania SQL lecz nie ma o ogólnym bezpieczeństwie skryptów.

1. Złe używanie include.

Często dołączamy pliki dynamicznie pobierając miejsce gdzie znajduje się plik metodą GET.

Przykładowy adres:
http://www.jakas-strona.pl/index.php?plik=katalog.php

Kod php:

[PHP] pobierz, plaintext 
<?php
include($_GET['plik']);
?>
[PHP] pobierz, plaintext 

Taki skrypt dokonałby dołączenia pliku katalog.php do skryptu lecz co by się stało gdyby włamywacz wpisał taki adres:
http://www.jakas-strona.pl/index.php?plik=...t-niszczacy.php

Dajmy na to że skrypt znajdujący się na serwerze hakera wygląda tak:

[PHP] pobierz, plaintext 
<?php
 
$katalog = opendir('./'); /* skrypt otwiera katalog w którym się znajduje (zostaje wywołany */
 
while ($plik = readdir($katalog)) {
 
	  unlink($file);
 
}
 
?>
[PHP] pobierz, plaintext 

No i jeżeli pliki w katalogu mają uprawnienia pozwalające na usunięcie ich przez skrypt to możemy się pożegnać z plikami w katalogu.

Jak temu zapobiec (IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif)

Rozwiązanie 1.

Tworzymy taki include:

[PHP] pobierz, plaintext 
<?php
include('./'.$_GET['katalog']);
?>
[PHP] pobierz, plaintext 

Taka instrukcja pozwala na dołączanie jedynie plików które znajdują się w katalogu ze skryptem czyli nie można załączyć pliku z innego serwera.

Ja narazie pamiętam tylko tyle lecz jeżeli znacie jakieś inne błędy popełniane przez programistów a także sposoby walczenia z nimi to się tutaj dopiszcie (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

Pozdrawiam

// prosiłbym moderatorów (jeżeli można) o przyklejenie tego tematu

---
Przyklejone - hwao

@fifi209: a to ta strona www.stopforumspam.com nie umożliwia pobrania bazy spamerów? Przeszukanie lokalnej bazy danych będzie bezporównania szybsze, niż wykonywanie rządań curlem. Do tego zautomatyzowany cotygodniowy update lokalnej bazy.

Umożliwia. (IMG:style_emoticons/default/smile.gif) Ale skoro udostępniają webapi to dałem przykład jak z niego korzystać.

Hey pytanie o bezpieczeństwo , co jest lepsze do zabezpieczenia się przed XSS :
htmlspecialchars($str, ENT_NOQUOTES, 'UTF-8') czy filter_var ( $val , FILTER_SANITIZE_SPECIAL_CHARS) ?

Ja uważam, że to drugie z ustawionymi flagami na stripowanie low (kody ASCII niższe niż 32) i high (kody ASCII powyżej 127). Ostatecznie zawsze można się zastanawiać nad sanitize_string. Zależy do czego konkretnie potrzebne. Ale to chyba sam wiesz z doświadczenia

A według mnie ta pierwsza metoda. Jest czytelniejsza, szybsza i nie do ominięcia.

@pyro - mógł byś podać argumenty/źródła dzięki którym masz taką pewność?

A który konkretnie argument masz na myśli?

No raczej o tego posta chodzi ~zendowi

Wiem, że o tego posta mu chodziło, ale pytałem o którą konkretnie rzecz mu chodzi:

- czytelniejsza (według mnie) - jest w przypadku dodatkowych flag dla filter_var. Programista często nie zna na pamięć wszystkich znaków ASCII, a htmlspecialchars() ma prostą i zrozumiałą budowę. Jednak jeżeli miałyby być one wywoływane dosłownie w ten sposób jak to napisał @Spawnm, to generalnie nie ma to różnicy
- szybsza - kiedyś zadałem sobie takie samo pytanie, więc potrudziłem się o testy. Różnica szybkości jest mało znacząca, ale jeśli już jesteśmy przy porównywaniu... (IMG:style_emoticons/default/smile.gif)
- nie do ominięcia - a co? Zna ktoś jakoś metodę, aby ominąć to filtrowanie?

A jak drugą można obejść?

Nie wiem czy się da (nie wiem czy ktoś już się potrudził o testowanie bezpieczeństwa tej funkcji), jednak wiem, że htmlspecialchars() na pewno się nie da.

Hey chcę dać userowi możliwość wstawiania linków przez bbcode na stronie www , i teraz pytanie:
czy taki kod:

[PHP] pobierz, plaintext 
//any string
$str='http://sadf.pl onclick="alert(1)"';
//filtr
$str=str_replace(array('%20','+',' ','"','\''),'',$str);
[PHP] pobierz, plaintext 

w 100% zabezpieczy mnie przed xss ?

Usunięcie ciągu javascript oraz wywalenie " jest wystarczające (oczywiście z linku)

Ten post edytował wookieb 8.07.2010, 10:27:56

A po co wywalenie ciągu javascript?
Link zawsze zaczyna się od http:// więc dodanie na końcu http://adsf.pl/java script:alert(1) nic nie da (IMG:style_emoticons/default/smile.gif)

A to kurcze już nie pamiętam jak to było (IMG:style_emoticons/default/smile.gif) To wtedy nie wystarczy samo usunięcie " albo zastąpienie go encja? Bo twoim zabezpieczeniem usuwasz możliwość podania niektórych prawidłowych linków (dlaczego usuwasz plus ?)

Hmm , pośpieszyłem się z tym '%20' i '+' , wydawało mi się że jak spacja to %20 lub + w adresie to i w html uzna te znaki .

o ile się nie mylę to niektóre przeglądarki też obsługują onclick=alert(1) tzn bez cudzysłowu, jeśli chodzi o doklejanie czegoś do url, to weź pod uwagę czy możesz wyświetlić treść usera w innym miejscu niż url + czy w serwisie nie masz jakiegoś skrytpu, którego zadaniem jest przekierowanie na inną stronę

Po prostu sprawdź czy podany tekst ma format URLa (ewentualnie możne mu brakować protokołu, wtedy dodaj HTTP) + zamień na encje to co zamienione być powinno (&, ", ') w przypadku używania w dokumencie HTML.

A jak najlepiej zapobiec zarejestrowanemu użytkownikowi na tworzenie kolejnych kont na stronie z innych ip oraz innych przeglądarek?
Pomyślałem o wrzuceniu usera IP do bazy lecz każdy wie że ono jest zmienne np u neostrady itd...

Czy zna ktoś może lepsze rozwiązanie?

Nie da się. Najlepiej zrobić 1 konto = 1 mail. Możesz także wbudować sto różnych zabezpieczeń, które oczywiście da się obejść (IMG:style_emoticons/default/smile.gif)