Witam,

od pewnego czasu ucze sie obiektowego php, tworzac wlasna strone internetowa. Jakie bylo moje zdziwienie gdy dzisiaj przestala ona poprawnie funkcjonowac. Strona odswieza sie sama co sekunde, co uniemozliwa jej poprawne funkcjonowanie. Po zweryfikowaniu kodu zrodlowego stronu zobaczylem nastepujacy kod:

<script type="text/javascript">
window.setTimeout("window.location.replace(ADRES_STRONY');",1);
</script>

Slyszalem o atakach XSS, ale nigdy ze tak powiem nie doswiadczylem tego na wlasnej skorze:) Z tego powodu chcialbym sie zapytac bardziej doswiadczonych kolegow jak temu zapobiec?

pozdrawiam
d

Szukając na forum.

to zależy, na jakie wprowadzanie tekstu chcesz pozwolić - jeśli najprostsze to po prostu wyświetlaj to co ktoś wpisze stosując jakąś funkcję w php w stylu htmlspecialchars

- jeśli z kolei chcesz pozwolić na wiele i nie dodajesz tekstu zbyt często to zainteresuj się DOM'em w php i usuwaj elementy script oraz style(by Ci nie przestylowali strony ^^) no i elementy link pod kontem pobieranych plików - lub też je usuwaj... w pozostałych elementach albo usuwaj wszystkie atrybuty mouseover (jest ich znacznie więcej) lub prościej zostawiaj tylko dozwolone atrybuty... w atrybucie href sprawdzaj czy nie zaczyna się od "java script:" - i dopiero dobrze obrobiony tekst przez dom zapisuj do bazy...

Prawda jest taka, że jeżeli nie puścisz htmlspecialcharsa lub nie pozbędziesz się wszystkich złych znaków, to użytkownik może ci zrobić ze stroną wszystko, np. umieścić iframe zasłaniający całą treść. Albo wykraść ciasteczka twojej strony, albo robić redirecta. W zasadzie nie powinieneś nigdy dopuścić aby użytkownik mógł sam wstawiać jakikolwiek tag html czy skrypt.

Ja spojrzałem na przykłady ataków i był taki specyficzny atak XSS:
\x3Ca href="" onmouseover="alert(document.cookie);" \x3ETUTAJ!\x3C/a\x3E
czy htmlspecialchars przefiltruje takie coś?

Tak, ale szybciej było chyba sprawdzić co?

Ehh, zawsze dodaje się do widoków edytowanych przez usera zewnętrznego htmlspecialchars($string);
Jest to konieczne !
Opuszczam to tylko i wyłącznie w przypadku edycji strony www w cms przy użyciu tinyMCE, no ale wiadomo, jest to admin, wszytko zabezpieczone hasłem, tak być musi.
Ale mimo to zawsze używam przed dodaniem do bazy addslashes(stripslashes($string)); i po wyciągnięciu z bazy w widoku daje stripslashes($string);
Przy dodawaniu daje stripslashes przed addslashes żeby przypadkiem nie powielały się \ przy włączonej dyrektywie magic_quotes w .htaccess
Przy wyświetlaniu usuwam wszystkie \
Oczywiście jeśli wprowadzał dane ktoś z zewnątrz to w widoku dajesz: echo htmlspecialchars(stripslashes($string)); i masz wszytko załatwione.

Stwórz sobie jakąś klasę, no nie wiem, validation i w niej walnij metody:

[PHP] pobierz, plaintext 
class Validation {
public function escape($string, $html = true) {
$string = stripslashes($string);
if($html) return htmlspecialchars($string);
else return $string;
}
public function escapeDB($string) {
return addslashes(stripslashes($string));
}
}
[PHP] pobierz, plaintext 

To ci eliminuje wszelkie niebezpieczeństwa

[PHP] pobierz, plaintext 
$validation = new Validation();
echo $validation->escape($string); // jeśli chcesz użyć htmlspecialchars
echo $validation->escape($string, false); // jeśli pozwalasz aby text zawierał javascript bądz xhtml
$query = 'insert into db values(1,"'.$validation->escapeDB($string).'")'; // dodawanie rekordów do bazy - wywala wszelkie niebezpieczne znaki dla zapytań SQL
[PHP] pobierz, plaintext 

Cudny, jestes hardcorem! Zapytan do bazy sie tak nie zabezpiecza (w przypadku MySQL jest to funkcja mysql_real_escape_string). Co do tekstu wyswietlanego na stronie - stary ale jary BBCode, wedlug mnie trzeba odroznic "HTML" wstawiany przez uzytkownikow od tego natywnego z aplikacji.

Zatem jestem harcorem
Czy kolega przeczytał najpierw jak działa funkcja addslashes(); ?
W przypadku kodowania utf8 jest ona bezpieczna dla sql injection bo nie jesteś w stanie dodać w żadnym wypadku pojedynczego znaku ' bądź "
Poniżej artykuł opisujący atak sql injection pomimo użycia addslashes:
http://shiflett.org/blog/2006/jan/addslash...l-escape-string
Proszę jednak zapoznać się z dopiskiem na końcu strony:

Wnioski:
Jak mądrze rozwiążesz aplikację to i validacja będzie łatwiejsza.
Oczywiście sam używam mysql_real_escape_string(); ale powyższy przykład udowadnia, że piszesz o czymś o czym nigdy nie czytałeś.
Warto zapoznać się z funkcjami predefiniowanymi w php

A tu ciekawostka dotycząca bezpieczeństwa mysql_real_escape_string(); przy użyciu kodowania ISO-8859-1
http://ilia.ws/archives/103-mysql_r...Statements.html

Nie ma super bezpiecznej validacji danych. Można jedynie zabezpieczyć dane bardzo dobrze, ale i tak znajdzie się na to sposób. SHA1 też zostało złamane i szybki komputer jest w stanie w (tu nie pamiętam dokładnego czasu, nie chce mi się szukać) tydzień czy dwa odczytać hasło wykradzione z bazy danych.
Niestety często się to zdarza przy backupach, wiec... jak piszą, "było włamanie do servisu, wykradziono hasła, ale nie martwcie się, były hashowane", to i tak zmień sobie to hasło. To taka ciekawostka sytuacyjna

Co do BBCode, nie widzę najmniejszego sensu używania go w aplikacjach, chyba że jest to forum.
Czemu ? A z racji wydajności.
Lepiej zapisać pełny html do pliku i potem require_once($file); niż przy użyciu wyrażeń regularnych parsować cały kod i zamieniać znaczniki.
Moim zdaniem lepiej mądrze rozwiązać widoki aplikacji niż używać BBCode.
Oczywiście możliwość tworzenia HTML w tym wypadku może mieć tylko i wyłącznie admin, czyli osoba odpowiedzialna za poprawne działanie całej aplikacji.
Możliwość tylko i wyłącznie po autoryzacji.
Jak zwalisz validacje logowania to i tak aplikacja nadaje się do kosza

długo używałem takiego rozwiązania, jakie podał @cudny byłem z niego bardzo zadowolony

Tak, oczywiscie ze nie wiem jak dziala addslashes... OFC!! Jak chcecie kombinowac to prosze bardzo, osobiscie nie widze w tym sensu skoro jest funckja przeznaczona do zabezpieczania zapytan, czego nie mozna powiedziec o addslashes