13:37
4/7/2011
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]
Posłuchaj jednego z naszych 8 cyberwykładów. Wiedzę podajemy z humorem i w przystępny dla każdego pracownika sposób. Zdalnie lub u Ciebie w firmie. Kliknij tu i zobacz opisy wykładów!
Każdy powinien zobaczyć te webinary! Praktyczna wiedza i zrozumiały język. 6 topowych tematów — kliknij tutaj i zobacz szczegółowe opisy oraz darmowy webinar.
Załatane w 3.1.4, czy jeszcze nie?
Według “szczegółów” – tak
http://core.trac.wordpress.org/ticket/14443
????
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”…
@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 )
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.
@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
@thewanderer – święta prawda. Streściłeś tu wszystko co można na ten temat powiedzieć :)