Rozdział 22 · Tworzenie stron internetowych z PythonPodstawy bezpieczeństwa aplikacji internetowych
Kilka typowych błędów i zasad, które musisz znać nawet przy małym projekcie.
Bezpieczeństwo w sieci to duży temat; oto tylko najczęstsze błędy i zasady, Że musisz wiedzieć nawet przy małym projekcie. Deep learning jest na przyszłość kurs specjalizacyjny (sekcja 22.36).
SQL- Zastrzyk
Jeśli złożysz zapytanie SQL-, łącząc łańcuch znaków tekstów z wejściem użytkownika, część wpisanej Tekst może być postrzegany jako część samego zapytania, a nie jako dane:
# NIE MOŻESZ TEGO ZROBIĆ
db.execute(f"SELECT * FROM tasks WHERE title = '{{user_input}}'")db.execute("SELECT * FROM tasks WHERE title = ?", (user_input,))sqlite3.execute() w Python nie pozwala na kilka SQL- instrukcji w jednym wywołaniu: atak złożony taki jak x'; DROP TABLE tasks; -- zawiodę ProgrammingError. To ograniczenie konkretnego sterownika Python-, a nie uniwersalna ochrona SQL. To nie chroni przed wstrzyknięciami jednoskładnikowymi: wprowadzenie ' OR '1'='1 zmienia stan WHERE i zwraca wszystkie linie. Nigdy nie wstawiaj niepewnego wejścia do tekstu SQL — przekazuj je tylko jako parametr.Rozdział 22.22 już pokazała tę technikę — parametryzowane zapytanie,
gdzie znaczenie jest przekazywane oddzielnie od SQL tekstu i nigdy nie jest z nim mieszane. Moduł
sqlite3 odpowiada za to, by wartość pozostała danymi,
Cokolwiek w niej jest, nawet fragment wyglądający jak SQL.
XSS — Skrypty międzyokręgowe
Jeśli obcy tekst trafi na HTML- stronę bez przetworzenia, może zawierać
kod wykonywalny, który zostanie uruchomiony w przeglądarce innego użytkownika — na przykład,
<script>...</script> w nazwie zadania. Rozdział
22.12 już wykazało ochronę: w kontekście HTML- z auto-shielding Jinja zastępuje specjalny
znaki HTML odpowiadające mu sekwencje escape-, więc wpisany tekst nie jest
interpretowane jako marż. To nie czyni bezpiecznego wstawiania wartości gdziekolwiek —
na przykład wewnątrz <script> lub URL potrzebuje już innej ochrony, — właśnie dlatego filtr |safe, co zazwyczaj jest
wyłącza escaping, nie może być zastosowana do wejścia, nad którym nie masz pełnej kontroli
siebie.
CSRF - Fałszerstwo żądań międzysymetrycznych
CSRF (Cross-Site Request Forgery) jest istotne, gdy przeglądarka działa automatycznie poświadczenia (np. sesja cookie, sekcja 22.30) dla żądań, a samo żądanie się zmienia Status serwera: Użytkownik zalogowany na stronie otwiera inną, złośliwą stronę Page, a teoretycznie ten Page mógłby wysłać prośbę w jego imieniu do Ciebie Strona — sama przeglądarka będzie stosować ten sam cookie. Dopóki w szkicu rozdziału nie ma logowania użytkownika, Ryzyko CSRF ograniczone, ale w zastosowaniach, gdzie autoryzacja lub status zależy od Automatycznie wysyłane przez przeglądarkę cookie zmieniające status żądań muszą być są chronione przed CSRF przez odpowiedni mechanizm, zwykle zapewniony przez sam ramowy system, lub Ekspansja.
Hasła
Hasła nigdy nie są przechowywane jako tekst zwykły, a jedynie jako skrót uzyskany przez Sprawdzone narzędzie stworzone specjalnie do haseł. Wymyśl własne Schemat haszowania haseł nie jest potrzebny i nie jest tego wart — są gotowe, starannie przygotowane zaufanych bibliotek. Projekt tego rozdziału w ogóle nie przechowuje haseł: sekcja 22.30 już wyjaśniono, dlaczego pełne logowanie użytkownika wykraczało poza zakres tego rozdziału.
Sekrety
SECRET_KEY aplikacje, hasła do baz danych, klucze zewnętrzne
API — wszystko to nie powinno trafiać do publicznego kodu źródłowego. Zazwyczaj takie wartości
Przechodzić przez zmienne środowiskowe zamiast zapisywać je bezpośrednio do pliku z
kodeks, w sekcji 22.34.
HTTPS — znowu, krótko
Rozdział 22.10 już wyjaśniła: HTTPS chroni dane po drodze między przeglądarką a ale nie naprawia błędów w samej aplikacji – SQL- wstrzykiwania, XSS czy wycieku HTTPS nie powstrzyma tajemnic. To różne, uzupełniające się poziomy ochrony.