W sumie najpierw trzeba by się zastanowić i sobie zgromadzić nazwę wszystkich podatności jakie chciałoby się wprowadzić do projektu. Nie mam na myśli tylko stwierdzenie SQL Injection tylko dla przykładu:
- SQL Injection w parametrze GET
- SQL Injection w parametrze POST
- SQL Injection w wyświetlanym gdzieś z boku user agent
- SQL Injection w innych nagłówkach HTTP*
- SQL Injection w ciastkach
- blind SQL injection
Potem to zmapować na prawdopodobne zagrożenia na stronach www przykładowo:
- Zmiana wyników stronnicowania newsów na stronie
- Logowanie się bez poprawnych danych do panelu admina za pomocą SQL Injection (POST)
- Wstrzykiwanie się do logów administratora z przeglądarkami odwiedzających
itd.
Dobre są takie przemyślenia moim zdaniem, aby nie pisać czegoś sztucznego a w miarę przypominającego realną aplikacje. Najlepiej żeby poziomy różnych ataków były zróżnicowane. Bo potem większość kojarzy SQL Injection dla przykładu z:
i płacze że nie działa. Brak im kreatywności w tym gdzie szukać luk, jak się wstrzelić i gdzie mogą być zwracane wyniki.
Tak samo wiele hackme jest sztucznych i nakazuje rozkminienie JavaScriptu w bez sensownym kodzie. Nie lepiej po prostu takie zadanie umieścić w takim dziurawym cmsie? Przykładowo walidacja kilku pól formularza na pewnej podstronie takiego skryptu może być po stronie klienta. Niech sama osoba trenująca wpadnie na to by zmodyfikować u siebie ten formularz w celu próby wstrzyknięcia innych rzeczy (XSS, SQL, itd).
To jest tylko moje zdanie i fajnie jakby cały ideologia też zachęcała do pisania exploitów prostych (nawet w php) pod ten cms w celach edukacyjnych i chwalenie się nimi na stronie projektu. Myślę że jeśli ktoś by pobawił się i napisał kilka to nie miałby problemu z odpaleniem każdego z sieci (tam często są literówki celowo wprowadzone).
