13:37
4/7/2011

Kilka błędów typu SQL injection odkryto w WordPressie 3.1.3 oraz 3.2-RC1. Już rola “Edytora” pozwala na pełny dostęp do wszystkich danych w bazie — szczegóły.

http://localhost/wp-admin/edit-tags.php?taxonomy=link_category&orderby=[SQL injection]&order=[SQL injection]
http://localhost/wp-admin/edit-tags.php?taxonomy=post_tag&orderby=[SQL injection]&order=[SQL injection]
http://localhost/wp-admin/edit-tags.php?taxonomy=category&orderby=[SQL injection]&order=[SQL injection]
http://localhost/wp-admin/link-manager.php?orderby=[SQL injection]&order=[SQL injection]

Ten wpis pochodzi z naszego linkbloga *ptr, dlatego nie widać go na głównej.
*ptr możesz czytać przez RSS albo przez sidebar po prawej stronie serwisu.

Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

9 komentarzy

Dodaj komentarz
  1. Załatane w 3.1.4, czy jeszcze nie?

    • Według “szczegółów” – tak

  2. http://core.trac.wordpress.org/ticket/14443
    ????

  3. Nie mogę tego pojąć. Czy naprawdę tak trudno jest stworzyć sobie obiekt PDOStatement i wywołać metodę execute z tablicą argumentów? (Rozumiem, żeby dziury były we własnych skryptach / programach CGI pisanych przez żółtodzioba traktującego strcpy() jak Święty Graal programowania…)
    Czy jeszcze ktoś oprócz mnie, na wieść o kolejnym ataku SQL Injection na kod pisany w PHP czuje się, jak gdyby tytuł artykułu brzmiał “Naukowcy zszokowani – jedenasta próba zasilania komputera piorunochronem TEŻ się nie powiodła”?
    “Bo kto się w pehapie połapie”…

  4. @thewanderer – nie do końca rozumiem Twoje żale odnośnie PHP. Fakt – język idealny to to nie jest, ale 90% takich wypadków to wina tylko i wyłącznie programisty. To, że język ma pewne, powiedzmy wprost: dziadowskie struktury, to nie oznacza, że każdy program/skrypt napisany w nim jest dziadowy. Wszystko zależy od programisty.

    • Owszem masz rację, ale pewnych rzeczy nie przeskoczysz. Jeśli siedzisz w czymś odpowiednio długo to wiesz jakie są tego słabe strony. Używaj javy albo asp.net jak chcesz bezpieczeństwa (jaki system płatności albo jaki bank używa php? :P :D )

  5. Dlatego jestem za tym, aby wycofywać PHP z serwerów na rzecz nowszych rozwiązań. W PHP nadal mamy działające stare rozwiązania łączenia się do baz danych i choć wszystkie nowe webaplikacje albo starają się przenieść na ich nowocześniejsze i bezpieczniejsze wersje to stare technologie nadal istnieją jako zachowanie funkcjonalności. Np. w Pythonie (czy to Djanog czy Pylons) rozwiązania bezpieczeństwa już są wbudowane w mechanizmy połączenia z bazami danych, a więc nie można dopuścić do takiej sytuacji.

  6. @Sobak: Ależ PHP to świetny język. Ba, zdarza mi się pisać skrypty systemowe w pehapie zamiast w Bashu.
    90% takich wypadków to wina tylko i wyłącznie programisty. Otóż to. Tym, co mnie zawsze zadziwia, jest: jak, mając do dyspozycji PDO, API do przygotowanych zapytań (prepared statements) i dziesiątki różnych bibliotek, funkcji czyszczących wejście, warstw abstrakcji, frameworków, a ponad tym wszystkim, wielkich, pisanych boldem ostrzeżeń nt. SQL Injection w książkach i poradnikach, programista potrafi wstawić input od użyszkodnika do zapytania.
    @zwierzak: Jeśli PHP ma jakieś przewinienie w tej kwestii, to jest to dostępność przestarzałych funkcji. Widać konflikt między kompatybilnością a bezpieczeństwem. Wspomniane przez Ciebie narzędzia (Django, Pylons) to frameworki – tak samo ciężko byłoby znaleźć coś np. w Zend Framework. Fakt, PHP jest powszechnie uważany za mało bezpieczny. Powód? Dużo dziur. W programach, które używają PHP, oczywiście, nie w samym PHP… To tak, jakby powiedzieć, że C jest dziurawe :D

  7. @thewanderer – święta prawda. Streściłeś tu wszystko co można na ten temat powiedzieć :)

Odpowiadasz na komentarz zwierzak

Kliknij tu, aby anulować

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: