@Stasiek, SQL Injection trywialne ? Czy Ty w ogóle masz pojęcie co mówisz ? A może jesteś jednym z tych pożal się boże "programistów" którzy sami siebie tak nazwali.
Na SQL Injection, XSS i parę innych ataków jest tyle różnych metod i sztuczek że się Ci w tej Twojej pale nie pomieści.
Mapowanie bazy danych czy Active Record odpowiednio zaimplementowane pomaga ale też programista który robi te rozwiązania musi wiedzieć co robić. Nie mówiąc o tym że co jakiś czas pojawia się w sieci jakaś nowa ciekawostka.

Najlepszy przykład ? Było włamanie na mysql.com. Oficjalnej stronie firmy należącej do Oracle gdzie zarówno Sun jak i Oracle siedzą w bazach danych od lat.

Ale zawsze są idioci którzy myślą że w PHP użyjesz addslashes i masz z głowy...

Taaa... Zwłaszcza, że addslashes jest dziurawe i w chwili obecnej jego uzycie wcale nie zabezpiecza mocno przed SQLInjection. Jesli chcesz się grzebać to mnóstwo kombinowania i mysql_real_escape_string. Chcesz lepszego zabezpieczenia? PDO i prepared_statements. To Cię niemal na pewno zabezpieczy. Przynajmniej do czasu aż w tym mechanizmie nie znajdą luki lub w pdo nie zaczniesz uzywać niezabezpieczonej metody pdo->query()

addslashes() nie sluzy do escapowania zapytan sqlowych. To ze matolectwo tego uzywa to nie znaczy ze rozumie co robi. Poczytaj manual na poczatek.

A tam niebezpiecznik jest za opensource nawet działa na darmowym WordPressie i darmowym szablonie pyrmont-v2, a opesource jest pro ;)

To, że 80% serwisów onet.pl jest podatnych na sql injection od kilku lat żadną tajemnicą nie jest. (-: Szkoda, że młody się pochwalił i zaczną to teraz łatać... :

Tak, nie jest żadną tajemnicą, administracja DI, wiedziała o tym od dawna, ale czekali aż 7 lat, aż ktoś im o tym napisze :D (ROTFL)

Pokażesz nam jakiś błąd na onecie?

@zigi: Czy ja pisałem, że używam tego? Jedynie tyle, że ludzie tego używają do zabezpieczenia się. Podałem w tym samym poście sposoby by się zabezpieczać przecież, a które z addslashes nie mają nic wspólnego. Poza tym powiedz mi w takim razie na czym polega najprostszy atak sql_injection jak nie na wstrzyknięciu do formularza przetwarzającego dane fragmentu, który wykorzystuje nie poprzedzony znakiem ucieczki apostrof, który dodaje warunek logiczny zawsze prawdziwy by uzyskać dostęp? Właśnie takiego typowi atakowi addslashes przeciwdziała. To, że nie działa zawsze w sposób prawidłowy to miejsce na inną opowieść. W chwili obecnej jedynie PDO i bindowanie parametrów lub forma tego dla ORMów używanych w projekcie, wyłaczanie autowspomagaczy typu magic_quotes (które robią większy burdel niż trzeba i działają właśnie na zasadzie użyj addslashes na każdej danej jaką masz).

dobrze, że ktoś wykrył taki błąd :/ i jeszcze lepiej, że programiści onet byli w stanie szybko go naprawić, młody pewnie znajdzie już niedługo pracę :)