Jest piątek, 16:47. Wdrażasz ostatnią poprawkę i zamykasz laptopa.
W poniedziałek rano czeka na Ciebie mail od klienta: "Dlaczego dane naszych użytkowników krążą po internecie?".
Nie znam gorszego początku tygodnia.
Problem w tym, że w większości projektów bezpieczeństwo to temat "na później". Goni deadline, sprint się kończy, a przecież "jesteśmy za mali, nikt nas nie zaatakuje". Aż w końcu ktoś zaatakuje - i wtedy żadnego "później" już nie ma.
Dlatego dziś dwie rzeczy:
1. Konkretna wiedza - 3 błędy bezpieczeństwa, które w kodzie C#/.NET widuję najczęściej. Sprawdź, czy nie masz ich u siebie.
2. Ogłoszenie - ruszyły zapisy do Szkoły Bezpieczeństwa C#/.NET, mojego szkolenia online. Szczegóły na końcu wpisu.
Zaczynamy od mięsa.
Błąd #1: SQL Injection — klasyk, który nie chce umrzeć
Wygląda niewinnie:
/* ❌ Tak nie robimy */
var query = $"SELECT * FROM Users WHERE Email = '{email}'";Wystarczy, że ktoś zamiast adresu e-mail wpisze ' OR '1'='1, i właśnie odczytał całą tabelę użytkowników. A to łagodny scenariusz - równie dobrze mógł ją usunąć.
"Kto dziś skleja SQL-e stringami?" - myślisz. A potem otwierasz ośmioletni projekt legacy i… no właśnie.
Jak się bronić? Zawsze parametryzuj zapytania - albo używaj EF Core / Dappera, które robią to za Ciebie:
/* ✅ Bezpiecznie */
var user = await context.Users
.FirstOrDefaultAsync(u => u.Email == email);Błąd #2: Hasła „zabezpieczone" przez MD5
Hasła w plain text to skrajność (choć wciąż się zdarza). Ale MD5 albo goły SHA-256? To niestety standard w wielu systemach.
Problem: te algorytmy są za szybkie. Współczesna karta graficzna liczy miliardy takich hashy na sekundę. Po wycieku bazy złamanie większości haseł to kwestia godzin.
Jak się bronić? Używaj algorytmów zaprojektowanych do haszowania haseł: PBKDF2, bcrypt albo Argon2. Jeśli korzystasz z ASP.NET Core Identity, masz to od ręki - wbudowany PasswordHasher robi robotę.
I żelazna zasada: nigdy nie implementuj własnej kryptografii. Nigdy.
Błąd #3: Sekrety w repozytorium
Connection string do produkcyjnej bazy w appsettings.json. Klucz API dodany "tylko na chwilę". Wszystko grzecznie scommitowane do gita.
"Ale to prywatne repo!" - jasne. Do momentu, aż dołączy zewnętrzny wykonawca, repo stanie się publiczne albo komuś wycieknie laptop. A historia gita nie zapomina - raz scommitowany sekret zostaje w niej na zawsze, nawet jeśli "usuniesz" go kolejnym commitem.
Jak się bronić?
• lokalnie: User Secrets (dotnet user-secrets),
• na produkcji: zmienne środowiskowe albo Azure Key Vault,
• a jeśli sekret już trafił do repo - traktuj go jako spalony i natychmiast go zrotuj.
To dopiero początek listy
SQL Injection, słabe haszowanie haseł, sekrety w repo - to 3 pozycje z bardzo długiej listy. Dalej są XSS, CSRF, SSRF, brute force, IDOR, błędna konfiguracja CORS, źle przechowywane tokeny…
Część z nich pokazywałem na webinarze „Top 10 Błędów Bezpieczeństwa w C#/.NET — Jak Się Przed Nimi Bronić". Ale webinar to za mało, żeby przejść od "wiem, że problem istnieje" do "umiem się przed nim skutecznie bronić w swoim projekcie".
Właśnie dlatego powstało pełne szkolenie.
Szkoła Bezpieczeństwa C#/.NET - zapisy otwarte
Szkoła Bezpieczeństwa C#/.NET to praktyczne szkolenie online dla programistów C#/.NET, na którym nauczysz się chronić aplikacje webowe przed realnymi atakami.
W skrócie:
• 10 modułów - od fundamentów po konkretne wektory ataku: SQL Injection, XSS, CSRF, SSRF, brute force i inne,
• maksimum praktyki - nie kończysz z samymi notatkami, tylko z gotowym, zabezpieczonym szablonem aplikacji SPA + ASP.NET Core Web API, którego użyjesz w kolejnych projektach,
• opieka mentora - nie zostajesz z tym sam: przechodzisz szkolenie pod okiem osoby, która odpowie na pytania i sprawdzi, czy idziesz w dobrą stronę.
Pełny program znajdziesz na stronie szkolenia:
👉 Zobacz szczegóły i zapisz się
Dlaczego akurat ja uczę bezpieczeństwa?
Bo dla mnie to nie jest teoria z książki.
Jestem twórcą aplikacji Szyfron - polskiego menedżera haseł. Kiedy budujesz aplikację, której jedynym zadaniem jest ochrona najbardziej wrażliwych danych użytkowników, bezpieczeństwo przestaje być "dodatkową funkcją". Jest produktem.
Wszystko, czego uczę w Szkole, przećwiczyłem w praktyce - na aplikacji, w której błąd bezpieczeństwa kosztowałby najwięcej.
Konkrety: terminy, cena, kod zniżkowy
• 🗓 Zapisy trwają od poniedziałku 20 lipca do piątku 24 lipca, do godziny 22:00. Potem zamykam drzwi.
• 💰 Cena regularna: 1997 zł.
• 🎁 Dla czytelników bloga mam kod alarm, który obniża cenę o 500 zł - płacisz 1497 zł.
Wystarczy, że podczas zakupu wpiszesz kod alarm w koszyku.
👉 Zapisz się do Szkoły Bezpieczeństwa C#/.NET
Masz pytania? Śmiało pisz w komentarzu - odpowiadam na każde.
PS. Kod alarm to nie przypadek. Lepiej, żeby alarm włączył się teraz, przy czytaniu tego wpisu - niż za pół roku na Twojej produkcji.
