Zasada zerowego zaufania do wprowadzanych danych powinna być wypisana wielkimi literami i wpajana wszystkim programistom. Należy ją stosować do wszelkich danych, które są pobierane przez aplikację, niezależnie od sposobu ich pozyskania. Należy traktować tę zasadę poważnie. Oto przykład, który w pewnych warunkach mógłby okazać się zgubny.

Proszę wyobrazić sobie najbardziej znienawidzone urządzenie techniczne instalowane na drogach – fotoradar z automatycznym rozpoznawaniem tablic rejestracyjnych. Namiastkę takiego urządzenia można zobaczyć na drodze krajowej numer 94. Technologia automatycznego rozpoznawania tablic rejestracyjnych działa w wielu miejscach, w tym także na nowym moście w Płocku. System taki pobiera obraz z kamery, rozpoznaje znaki tablicy za pomocą aplikacji OCR, dopasowuje je do schematu, ale najpierw wrzuca pobrane znaki do bazy danych.
Proszę pomyśleć co by było, gdyby przed takim urządzeniem przejechał samochód oznakowany jak niżej:(zdjęcie pochodzi z serwisu http://dabroz.scythe.pl)

ZU O666′, 0,0); DROP DATABASE TABLICE;–

albo

T0 HVVDP’,0,0); TRUNCATE TABLE TABLICE;–

Tablice ZU O666 oraz T0 HVVDP (własny wyróżnik w województwie świętokrzyskim) spełnią podstawy szablonu, gdyby zatem narzędzie OCR rozpoznawało także cudzysłowy, nawiasy i średniki (co czasami ma miejsce, gdy deweloper nie ograniczy alfabetu), do aplikacji zapisującej dane w bazie przekazana byłaby treść jak wyżej. Powszechna niedbałość o kod nie pozostawia wątpliwości, że SQL Injection taką drogą da się zrobić i eksploitowanie podobnego błędu spowodowałoby utratę danych.

Wątpię czy żart ten działa naprawdę, ale pokazuje, że nawet przy pobieraniu danych z rozwiązań OCR (na przykład przy rozpoznawaniu dokumentów przychodzących do firmy) należy koniecznie zabezpieczyć się przed wstrzyknięciem kodu.