Jeśli chodzi o programowanie zwinne, jakie są najlepsze praktyki testowania zabezpieczeń w wydaniu?Czy istnieją sprawdzone metody testowania bezpieczeństwa w sklepie deweloperskim Agile?
Jeśli jest to wydanie miesięczne, czy co miesiąc odbywają się testy penów?
Nie jestem ekspertem od programowania Agile, ale wyobrażam sobie, że dobrym początkiem byłoby zintegrowanie podstawowego oprogramowania do automatycznych testów piórkowych z cyklem budowy. Widziałem kilka pakietów oprogramowania, które wykonują podstawowe testy i są dobrze przystosowane do automatyzacji.
Nie jestem ekspertem ds. Bezpieczeństwa, ale uważam, że najważniejszym faktem, z którego należy zdawać sobie sprawę, przed testowaniem zabezpieczeń, jest to, co próbujesz chronić. Tylko jeśli wiesz, co próbujesz chronić, możesz przeprowadzić poprawną analizę swoich środków bezpieczeństwa i dopiero wtedy możesz rozpocząć testowanie tych zaimplementowanych środków.
Bardzo abstrakcyjny, wiem. Uważam jednak, że powinien to być pierwszy krok każdego audytu bezpieczeństwa.
Unit testing, Defense Programming i wiele dzienników
testów jednostkowych
Upewnij testowych jednostki tak wcześnie, jak to możliwe (na przykład hasło powinno być szyfrowane przed wysłaniem, tunel SSL działa, itp) . Zapobiegnie to przypadkowemu nieprzyjemności programu.
Programowanie obrony
Osobiście nazywają to Paranoid Programowanie ale Wikipedia nie jest źle (sarkazm). Zasadniczo, dodajesz testy do swoich funkcji, które sprawdzają wszystkie wejścia:
Logging
Log wszystko jak szalony. Łatwiej jest usunąć dzienniki, a następnie je dodać. Użytkownik się zalogował? Zaloguj się. Użytkownik znalazł 404? Zaloguj się. Administrator edytował/usunął wpis? Zaloguj się. Ktoś mógł uzyskać dostęp do strony z ograniczeniami? Zaloguj się.
Nie zdziw się, jeśli plik dziennika osiągnie 15 MB podczas fazy projektowania. Podczas wersji beta możesz zdecydować, które logi usunąć. Jeśli chcesz, możesz dodać flagę, aby zdecydować, kiedy określone zdarzenie zostanie zarejestrowane.
Jaka jest twoja domena aplikacji? To zależy.
Odkąd użyto słowa "Zwinność", domyślam się, że jest to aplikacja internetowa. Mam dla ciebie łatwą odpowiedź.
Kup egzemplarz Burp Suite (jest to wynik Google nr 1 za "beknięcie" - pewne potwierdzenie!); kosztować 99EU lub ~ 180 USD, lub 98 dolarów Obama, jeśli poczekasz do listopada.
Burp działa jako serwer proxy. Przeglądasz swoją aplikację internetową za pomocą przeglądarki Firefox lub IE lub cokolwiek innego, i gromadzi wszystkie generowane przez Ciebie hity. Te trafienia są przekazywane do funkcji o nazwie "Intruder", która jest fuzzerem internetowym. Intruz wymyśli wszystkie parametry, które podasz do każdej z procedur obsługi zapytań. Następnie spróbuje szalonych wartości dla każdego parametru, w tym metaznaków SQL, systemu plików i HTML. W typowym postie złożonych formularzy wygeneruje to około 1500 trafień, które przejrzysz, aby zidentyfikować przerażające - lub, co ważniejsze w kontekście Agile, nowe - odpowiedzi na błędy.
Fuzzing każdego programu obsługi zapytań w twojej aplikacji internetowej przy każdej iteracji wydania jest # 1 rzeczą, którą możesz zrobić, aby poprawić bezpieczeństwo aplikacji bez ustanawiania formalnego "SDLC" i dodawania pracowników. Poza tym sprawdź swój kod pod kątem najważniejszych zabezpieczeń aplikacji internetowych:
Używaj tylko sparametryzowanych przygotowanych instrukcji SQL; nie należy nigdy łączyć łańcuchów i podawać ich do obsługi bazy danych.
Filtr wszystkie wejścia do białej listy znanych dobrych znaków (alnum, podstawowe znaki interpunkcyjne) i, co ważniejsze, filtrowanie danych wyjściowych z wyników zapytań do „neutralizują” metaznaki HTML do podmiotów html (quot, lt, gt itp.).
Użyj długich losowych identyfikatorów trudnych do odgadnięcia w dowolnym miejscu, w którym obecnie używasz prostych identyfikatorów wierszy całkowitych w parametrach zapytania i upewnij się, że użytkownik X nie widzi danych użytkownika Y przez zgadywanie tych identyfikatorów.
Przetestuj wszystkie programy obsługi zapytań w swojej aplikacji, aby upewnić się, że działają tylko wtedy, gdy jest wyświetlany prawidłowy, zalogowany plik cookie sesji.
Włącz ochronę XSRF w stosie internetowej, która będzie generować ukrytym formularzu tokenów parametrów na wszystkich świadczonych formach, aby uniemożliwić napastnikowi od stworzenia złośliwych linków, które złożą formularze do niczego nie podejrzewających użytkowników.
Użyj bcrypt --- i nic więcej --- do przechowywania haszowanych haseł.
+1 Cóż złożyć, @David. Ja * jestem * ekspertem ds. Bezpieczeństwa i jakoś wciąż widzę tak zwanych "ekspertów", którzy nie otrzymują tej podstawowej zasady. – AviD