środa, 15 października 2014

Dispel your security concerns - Spring Security part2 (mongoDB,Thymeleaf,boot)

Spring Security konfiguracja część 2. 
Rozwiewanie wątpliwości ;)
Wstęp do tematu znajdziesz w tym poście.
Kata na dzisiaj: (szybka implementacja)
Zadanie : Spring Security  - Custom web
page  + model domenowy w MongoDB
Chronimy URL + stosujemy CSRF.
Web - ThymeLeaf + webjars (bootstrap ,jquery)
Pamiętaj : 
Security to cross-cutting concern - nie mieszaj implementacji bezpieczeństwa z implementacją businesową.
TIP : Opieraj się na AOP, DI czy Sevlet filters


Po cholerę to piszę ?....
Jeśli porywasz się na implementację aplikacji wystawionej w sieci bez pomocy frameworka typu Spring Security to masz dużo fantazji, a może czasu na stworzenie własnych rozwiązań. Może treść czy dane, które serwujesz są po prostu gówno warte ?:). Problemy security są złożone a własna implementacja zabezpieczeń problematyczna - testowanie trudne. Tak czy inaczej bez odpowiedniego frameworka wspierającego Security znajdziesz się w dupie ....

Wystarczy spojrzeć na OWASP. by zrozumieć co Cię czeka...
Teraz spójrz na Spring Security reference. (a oferuje dużo :))

Kiedyś CSRF pisałem z palca. Teraz mam to out-of-the-box w Spring-Security.
TIP  : Pamiętaj, że CSRF protection jest włączone z default przy konfiguracji Java Config. Aby bo wyłączyć użyj :
 

OWASP Top Ten

1. Injection - Criteria API , JPQL Binding, QueryDSL, Spring JDBCTemplate,Escaping, WhiteListing
2. Cross-Site Scripting (XSS) - Spring Security 3.2 upper, th:text, JSR 303 hibernate validator @SafeHtml
3. Broken Authentication and Session Management - Spring Security, session-management
4. Insecure Direct Object References
5. Cross-Site Request Forgery (CSRF) - Spring Security 3.2 upper - domyślnie
low session timeout, random generated token, again login in case of sensitive sites
6. Security Misconfiguration- configure logging, exception handling, right security configuration policy
7. Insecure Cryptographic Storage - Spring Security np : OpenId, Jasypt,Spring Security crypto, never log any sensitive data uncrypted , encrypt db for sensitive data , choose right crypt algorithm, change keys and passwords periodically
8. Failure to Restrict URL Access - Spring Security
9. Insufficient Transport Layer Protection - Spring Security, secure session cookie
10. Unvalidated Redirects and Forwards- avoid redirects wherever possible, validate target URL
 
Tip : rozważ użycie HDIV !!- o tym w następnych postach

Ale .... Zaczniemy od bardzo fajnego features'a z Gradle.
czyli Resolution.

Generalnie chodzi o upewnienie się, że pobierzemy odpowiednie wersje zależności :

Przykład z dokumentacji Gradle :
Płynie powracamy do Spring Security configuration  :
http auto-config="true" - włączenie uwieżytelniania korzystającego z formularzy (włączenie łańcucha filtrów) - typowa domyślna konfiguracja dla Web

use-expression="true" -  włączenie wyrażeń SpEl dla Springa, przydatne np w JSP

create-session={} - session fixaction attack

form-login default-target-url="/welcome.html" - przekierowanie na danego URL'a po udanej autentykacji.

authentication-failure-url - przekierowanie na danego URL'a po nieudanej akcji autentykacji

remember-me - włączona opcja zapamiętywania

logout logout-success-url="/welcome.html" - konfiguracja operacji wylogowania - przekierowanie na danego URL'a po udanej akcji wylogowania

authentication-manager - manager uwierzytelniania wpółgra z authentication-provider

authentication-provider - dostawca uwierzytelnienia podpinamy tu jakąś logikę np DAO
Może to być dowolna interpretacje UserDetailsService czyli np implementacja w pamięci dostarczona przez Spring-Security czyli InMemoryDaoImpl


Http Basic Authentication ->  użyj : <http-basic />

Form Based Login -> użyj <form-login /> z default Spring Security wygeneruje dla Ciebie prosty formularz który znajdziesz pod URL'em /spring_security_login

Ok, spróbujemy to zrobić za pomocą JavaConfig. -> Czyli Start..:)
Na sam początek może startowy przykład z dokumentacji Spring Security:

Po kolei :
1.Upewniam się , że żaden request nie przejdzie przez filtry jeśli użytkownik nie będzie zalogowany.
2. Zezwalam na autentykacje przez form based login
3. Zezwalam na autentykacje przez HTTP Basic
Tyle. To jest bardzo podstawowa konfiguracja i dobrze właśnie z niej wyjść.

Zaczynam od potrzebnych zależności () :
Konfiguracja security :

Zawsze możesz customize'ować na kształt konfiguracji poniżej :

Konfiguracja mongoDB :

Konfiguracja dao :
Konfiguracja thymeLeaf :
Konfiguracja szyfrowania (teraz szyfruje tylko hasło w bazie, o zaawansowanych metodach szyfrowania - jasypt przeczytasz w następnych postach:) )
Model domenowy jest prosty : pamiętaj o UserDetails impl 

Db populate:


 








Potrzebuje impl UserServiceDetailsImpl aby podłączyć ją do authentication-managera
W celu podcięcia jakieś funkcjonalności zawsze używaj handlerów (np logowanie zdarzeń do bazy czy inne mierniki). Przykładowe handlery są poniżej :
Mechanizm logowania i wylogowania z CRSF w thymeleaf wyglądają jak poniżej :
Webjars w Thymeleaf :
Krótki post opisujący jak możesz za modelować sobie proste security.
Jeśli chcesz zabezpieczyć metody biznesowe - proszę :

Szybki Test

Testujemy Web :)



Po zalogowaniu :












Wszystko wygląda prosto. Ale wbrew pozorom można popełnić kilka błędów.
Taki PoC stworzyć jednak można szybko. Security oparte na formularzu jest jak widać proste - ale dla wprawionych. Konfiguracja w Xml wydaje się być bardziej przejrzysta niż JavaConfig DSL w wydaniu Spring Security. My jednak konsekwentnie odchodzimy na ile to możliwe od Xml'a.

Na koniec kolejny fajny feature:

Kod do posta znajdziesz tutaj;)

Brak komentarzy:

Prześlij komentarz