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.
