Paweł Goleń, blog

Co do zasady wykorzystanie pewnej dodatkowej “warstwy abstrakcji” ogranicza ryzyko związane z błędami typu SQL Injection. Ogranicza, ale nie eliminuje, bo:

• ta “warstwa abstrakcji” może być źle użyta,
• w wykorzystanym rozwiązaniu mogą być błędy,

I tak właśnie jest w przypadku Ruby on Rails: SQL Injection Vulnerability in Ruby on Rails (CVE-2012-5664) (patrz też: Rails 3.2.10, 3.1.9, and 3.0.18 have been released!).

A teraz pytania, które zadawałem programistom na szkoleniu, i na które odpowiedź brzmiała zwykle “nie”:

• czy jesteś w stanie wymienić wszystkie biblioteki, z których korzysta Twoja aplikacja,
• czy śledzisz informacje o nowych wersjach wykorzystanych bibliotek,
• czy jesteś pewny, że są one aktualne,

Pojęcie “biblioteki” jest tutaj pewnym placeholderem. Patrz też: Remember the Giblets! i The Trouble with Giblets.

Błąd w takim “dodatku” nie jest błędem w Twoim kodzie, ale jest błędem w Twojej aplikacji. Jeśli używasz cudzego kodu, musisz o niego dbać (On handling your pets and a CSRF protection that wasn't). Absolutne minimum to:

• wiedzieć co się użyło (a wybierać rzeczy do użycia też trzeba z głową!),
• śledzić informacje na temat użytych elementów,

A co, kiedy ktoś mówi “nie mogę zagwarantować, że po aktualizacji nasz system będzie nadal działał”? Cóż, z tym też można sobie poradzić: Test-driven development.

Oryginał tego wpisu dostępny jest pod adresem SQLi w RoR

Autor: Paweł Goleń