10:55
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

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.

7 komentarzy

Dodaj komentarz
  1. 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.

  2. 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ś.

  3. 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ń

  4. Jak sprawdzić czy dany hosting zapaczował błędy? poprzez php_info?

Twój komentarz

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