XSS i SQL Injection + ORM

[Ravgor]

Witam. Zabezpieczam dane z formularza przez metodę Security::xss_clean(), jednak do bazy zapisują się wszystkie znaki jakie wpiszę (np. cudzysłowia, apostrofy). Kiedy zabezpieczałem dane przez mysql_escape_string(), przed znakami specjalnymi pojawiały się backslashe. Dlaczego tu się tak nie dzieje i jak sprawdzić, czy kod został zabezpieczony przez xss_clean() i rzeczywiście nikt mi się nie włamie do bazy?

[nediam]

Mylisz pojęcia mówisz o XSS Injection a masz na myśli SQL Injection. Przed XSS ta fankcja bardzo dobrze chroni Przed SQL Injection wcale

[mck]

przed sql injection chroni defaultowe eskejpowanie zapytań, więc o to raczej nie trzeba się martwić

[barat]

Przed atakami SQL chroni Cie używanie Query Builder/ORM
Jest jeszcze escape()

[Ravgor]

Rzeczywiście pomyliłem rodzaje ataków. Zamiast xss_clean() użyję HTML::chars(), bo nie chcę w ogóle html'a w wyświetlaniu tekstu. Natomiast jeśli chodzi SQL injection, taki kod będzie bezpieczny?

$page = ORM::factory('page')->find(1);
$page->url = $_POST['url'];
$page->tresc = $_POST['tresc'];
$page->tytul = $_POST['tytul'];
$page->save();

Jeśli tak, prosiłbym o wytłumaczenie w jaki sposób się to dzieje, skoro w bazie przed apostrofami nie ma backslash'y.

[barat]

Rzeczywiście pomyliłem rodzaje ataków. Zamiast xss_clean() użyję HTML::chars(), bo nie chcę w ogóle html'a w wyświetlaniu tekstu. Natomiast jeśli chodzi SQL injection, taki kod będzie bezpieczny?

$page = ORM::factory('page')->find(1);
$page->url = $_POST['url'];
$page->tresc = $_POST['tresc'];
$page->tytul = $_POST['tytul'];
$page->save();

Jeśli tak, prosiłbym o wytłumaczenie w jaki sposób się to dzieje, skoro w bazie przed apostrofami nie ma backslash'y.

zamiast $_POST uzywaj biblioteki input - będziesz miał XSS z głowy
Co do zabezpieczenia bazy - po prostu QB/ORM nie przepuści ataków bo automatycznie quotuje wszystko jak trzeba - buduje zapytanie z klocków
A żeby były slashe to masz $db->escape()

[Zepco]

zamiast $_POST uzywaj biblioteki input - będziesz miał XSS z głowy
Co do zabezpieczenia bazy - po prostu QB/ORM nie przepuści ataków bo automatycznie quotuje wszystko jak trzeba - buduje zapytanie z klocków
A żeby były slashe to masz $db->escape()

Nie wiem jak w KO3, ale w KO2 $_POST był filtrowany przez xss już w momencie inicjowania biblioteki input.
W KO3 jest biblioteka input? Z tego co widziałem, to $_POST i inne tego typu zmienne są czyszczone i można korzystać tylko z $this->request->post itp. Ale one chyba tylko są obrabiane ze slashy i nic poza tym.
Do XSS jest  

Security::xss_clean();

Prawdopodobnie tak jak w przypadku routingu deweloperzy doszli do wniosku (i w sumie słusznie), że filtrowania dokonasz na poziomie walidacji.

[Ravgor]

Żeby zabezpieczyć $_POST przed XSS'em, wystarczy dodać taką linijkę:

$_POST = Security::xss_clean($_POST);

Natomiast ja bardzo się przyzwyczaiłem do zabezpieczania przed XSS'em przy wyświetlaniu danych, a nie zapisywaniu.

@barat
Właśnie nie wiedziałem co ten ORM robi, żeby zabezpieczyć się przed SQL inj. Teraz mi to trochę rozjaśniłeś. IMHO ORM tworzy takie zabezpieczenia jak phpMyAdmin, czyli np. z zapytania

UPDATE `pages` SET `napis` = 'O'Connor WHERE `id` =1

tworzy

UPDATE `pages` SET `napis` = 'O''Connor' WHERE `id` =1

czyli przed znakiem apostrofu dodaje drugi apostrof.

Wielkie dzięki wszystkim za pomoc .

[Zepco]

Żeby zabezpieczyć $_POST przed XSS'em, wystarczy dodać taką linijkę:

$_POST = Security::xss_clean($_POST);

Natomiast ja bardzo się przyzwyczaiłem do zabezpieczania przed XSS'em przy wyświetlaniu danych, a nie zapisywaniu.

A co w przypadku gdy pod jakąś zmienną posta będzie tablica?
W sumie to sam post też jest tablicą, a ta funkcja działa zdaje się tylko na stringi.

[Maciek]

A co w przypadku gdy pod jakąś zmienną posta będzie tablica?
W sumie to sam post też jest tablicą, a ta funkcja działa zdaje się tylko na stringi.

Nie ma obawy, działa też rekurencyjnie dla tablic i obiektów (źródło).

[Zepco]

Musieli to niedawno poprawić, bo ja tego nie mam w źródle. W takim razie nie było pytania.

Edit:
Poprawka była 4 grudnia. No to jestem trochę do tyłu.