18/8/2011
Trzy aktualizacje dla Rails 2.3.14, 3.0.10 oraz 3.1.0.rc6 zawierają poprawki dla 4 poważnych błędów bezpieczeństwa.
Response Splitting
Błąd w kodzie odpowiadającym za filtrowanie Content-Type pozwala atakującemu na wstrzyknięcie nagłówków HTTP do odpowiedzi serwera.
Versions Affected: 2.3.x.
Not affected: 3.0.0 or later
Fixed Versions: 2.3.13
SQL injection w quote_table_name
Metoda quote_table_name służąca do filtrowania nazw tabel zaczęła być wykorzystywana do innych celów (w tym escape’owania danych pochodzących od użytkownika) i przez to wymaga “uszczelnienia”.
Versions Affected: All.
Fixed Versions: 3.0.10, 2.3.13, 3.1.0.rc5
XSS w strip_tags
Można było oszukać helper strip_tags zaprojektowany do usuwania tagów HTML ze stringów. Helper ten najprawdopodobniej w przyszłych wersjach zostanie zastąpiony przez składową libxml. Aby ulepszyć escaping HTML zaleca się zainstalowanie gemu loofah.
Versions Affected: All.
Fixed Versions: 3.0.10, 2.3.13, 3.1.0.rc5
XSS (dla Ruby 1.8)
Bład w wyrażeniach regularnych w Ruby 1.8 powoduje, że niektóre dane mogą nie być escape’owane przez ERB::Util.h.
Versions Affected: 2.0.0 and later running on Ruby 1.8.x.
Not Affected: Applications running on Ruby 1.9.x
Fixed Versions: 3.0.10, 2.3.13, 3.1.0.rc5
Filter Skipping
Błąd w wyborze template’ów pozwala atakującemu na wygenerowanie widoku, do którego nie powinien mieć dostępu.
Versions Affected: 3.0.0 and Later
Not affected: Versions prior to 3.0
Fixed Versions: 3.0.10, 3.1.0.rc6
Weź udział z kolegami w jednym 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.
Ehh, gdzie te czasy, że trzeba było myśleć jak pisać. Teraz się wrzuca frameworka i żyje w błogiej nieświadomości problemu, a problem nie znika, tylko zmienia swoje położenie.
Jasne, bo człowiek jest nieomylny i zawsze pamięta o całej budowie systemu, czy już sprawdzał, jakie dane dopuszczane co potwierdza ogrom ataków np.buffer_overflow. Framworki upraszczają system, ułatwiają walidację, zwiększają bezpieczeństwo. Poza tym walidację jak w wszystkich wymienionych dziurach można przeprowadzać błędnie, więc trzeba zawsze sprawdzać czy działa. Trzeba zaufać czemuś kiedyś.
Ufać należy przede wszystkim sobie i swojej wiedzy, a do obcych produktów należy podchodzić z dużą nieufnością.
Frameworki o ile upraszczają i ułatwiają wiele rzeczy (lenistwo!), to zwiększają możliwą liczbę punktów awarii i w efekcie wg mnie zmniejszają bezpieczeństwo. Jak widać powyżej – błędy w zasadzie trywialne, na poziomie szkolnym.
…odważna teza ;)
Pisz zawsze wszystko od zera. Nie ważne ile osób sprawdzi coś, pisz każdorazowo od zera. Łącznie z systemem operacyjnym, serwerem itd. PHP samo w sobie też miewało błędy. PHP jest złe i będziesz pisać od 0 samemu? Oczywiście kompilator też może mieć błędy, więc…
Abstrahując od tego, że frameworki często wymuszają prawidłowe rozwiązania jak np.PDO i konstrukcja zapytań w nim(przy okazji escapowanie ich przez PDO) zamiast statyczne konstruowanie zapytań
Jak sprawdzić czy dany hosting zapaczował błędy? poprzez php_info?
Czytaj https://secure.wikimedia.org/wikipedia/pl/wiki/Ruby_%28j%C4%99zyk_programowania%29 , https://secure.wikimedia.org/wikipedia/pl/wiki/Ruby_on_Rails . Ruby !==PHP
Twoje rozwiązanie przez phpinfo() nie zadziała. Możesz wykorzystać polecenia rails -v lub gem list rails | grep \(*\)