Z SQL Injection jest jak z polio czy odrą: w drugiej dekadzie XXI wieku możemy o nim zapomnieć. Wystarczy się zaszczepić, czyli: nie sklejać ręcznie poleceń SQL. Prawda?
“Użyj parametrów z ADO.NET, a będzie cacy” – mówili. “Użyj Simple.Data, a złęgo obawiać się nie musisz” – mówili. Ależ kłamali!
Jakież przeogromne było moje zdziwienie, gdy niedawno dostałem buga mówiącego, iż “coś dziwnego się dzieje jeśli w nazwie rekordu wstawi się apostrof”. WTF, jak to? Oczywiście sugestią naprawienia błędu od strony biznesu było “zabronienie wstawiania apostrofu w nazwę rekordu” :). No tak…
Inwestygacja ruszyła pełną parą. Czy to coś w Simple.Data, jakiś brzydki babol? Ano nie, niemożliwe! Czy to w takim razie coś w naszym prywatnym buildzie Simple.Data.PostgreSql? Nie, też nie… A więc…
TAK! Wyobraźcie sobie, że błąd krył się w najpopularniejszym dotnetowym driverze do Postgresa: Npgsql. To było ostatnie miejsce, w którym się go spodziewałem. A jednak…
Chodzi o wersję 2.2.5, która, patrząc na statsy na Nugecie, jest najpopularniejszą wersją w historii tej paczki (ponad 32tys ściągnięć). Mało tego, w wersji 2.0.11 problem nie występował!
Sql injection było możliwe przy wykorzystaniu postgresowego typu CITEXT. Nie był on jawnie traktowany przez Npgsql jako tekst, więc nie był też odpowiednio “escapowany”. Dacie wiarę?
Na szczęście zespół bardzo szybko uwinął się z problemem i już jeden dzień po zgłoszeniu na nugecie pojawiła się poprawiona wersja 2.2.6. Jeżeli korzystasz z Postgresa w .NET to koniecznie zrób update!
Linki do zgłoszonego issue, warto poczytać i zobaczyć na czym polegał fix: https://github.com/npgsql/npgsql/issues/734.
Błędy się zdażają. To normalne. Mi jednak najbardziej podoba się sposób rozwiązania problemu. Z tego co widzę to 3 dni i koniec. To jest piękne.
2 dni nawet. Po tym można poznać dojrzały projekt OSS – super. Tym bardziej że v2 już nie jest rozwijane i budują v3, która z v2 nie ma tak wiele wspólnego.
SQL Injection alert!
Dziękujemy za dodanie artykułu – Trackback z dotnetomaniak.pl
Na tegorocznym SQLDay Adreas Wolter poprowadził ciekawą prezentację w czasie której udowodnił, że samo ‘zabronienie wstawiania apostrofu’ i użycie parametrów w ADO.NET nie chroni nas przed SQL Injection. Być może ten trik z query zapisanym w hexie to tylko bolączka SQL Servera, ale i tak daje do myślenia. Dla zainteresowanych link do materiałów z prezentacji: http://sqlday.pl/materials2015/SQLServerUnderAttack_SQLInjection.pdf .
A co do czasu reakcji tworców Npgsql, to oczywistym jest, że FOSS z rosnącą popularnością i potencjałem na wykorzystanie przy komercyjnych projektach w skali korpo musi być zarządzny w sposób profesjonalny, bo inaczej umrze lub pójdzie w obce rynce. Tak jak ostatnio mówiłeś – nadszedł czas na rozbudowę i profesjonalizację bloga, bo klimatyczny, nerdowski wygląd nie pomoże przy poszerzaniu grona słuchaczy ;).