13:37
4/7/2011

* WordPress: SQL injection

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]

Przeczytaj także:

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.

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ć :)

Twój komentarz

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

RSS dla komentarzy: