...
Example Realm elements are included (commented out) in the default $CATALINA_BASE/conf/server.xml file. Here's an example for using a MySQL database called "authority", configured with the tables described above, and accessed with username "dbuser" and password "dbpass":<Realm
| Code Block |
|---|
className="org.apache.catalina.realm.JDBCRealm" |
...
driverName="org.gjt.mm.mysql.Driver" |
...
connectionURL="jdbc:mysql://localhost/authority?user=dbuser&password=dbpass" |
...
userTable="users" userNameCol="user_name" userCredCol="user_pass" |
...
userRoleTable="user_roles" roleNameCol="role_name"/> |
- DataSourceRealm - Accesses authentication information stored in a relational database, accessed via a named JNDI JDBC DataSource.
- JNDIRealm - Accesses authentication information stored in an LDAP based directory server, accessed via a JNDI provider.
- UserDatabaseRealm - Accesses authentication information stored in an UserDatabase JNDI resource, which is typically backed by an XML document (conf/tomcat-users.xml).
- MemoryRealm - Accesses authentication information stored in an in-memory object collection, which is initialized from an XML document (conf/tomcat-users.xml).
- JAASRealm - Accesses authentication information through the Java Authentication & Authorization Service (JAAS) framework.
Configure Java EE authentication in web.xml to use Confidential transport which will make use of SSL, any request to a resource over plaintext HTTP will be redirected to HTTPS.
| Code Block |
|---|
<user-data-constraint> |
...
<transport-guarantee>CONFIDENTIAL</transport-guarantee> |
...
</user-data- |
...
constraint>
|
Implement Client Certificates:
A 2.2.2. Implement Client Certificates:
...
- Create a Certificate Authority
- Tell Tomcat to trust the CA
- Create a client certificate
- Sign on with the client certificate
A 2.2.3 Spring Security Framework:
| Code Block |
|---|
<intercept-url pattern="/**" access=isAuthenticated()" /> |
This configuration will require authentication for access to any of the application pages.
A 2.2.4 Secure Password Storage:
- Don't store plaintext passwords
- Store password in hashes using an algorithm without known weakness like SHA-256 or higher such as Java Symplified Encryption (Jasypt). This library has a StrongPasswordEncryptor class that automatically performs 100000 iterations of the SHA-256 algorithm along with a random 16 byte salt value. In addition, Jasypt provides the ability to encrypt values in property files using password-based encryption (PBE).
- Use a salt to mitigate rainbow table attacks
- Use a technique to slow down hashing speedStrongPasswordEncryptor speed
| Code Block |
|---|
StrongPasswordEncryptor bpe= new StrongPasswordEncryptor(); |
...
bpe.encryptPassword("example"); |
...
2.2.5 Password Policies:
- - Password Password length larger than 15 characters
- - No No dictionary words or common phrases
- - AlphaAlpha, numeric and special characters
- - Password Password age between 10 and 30 days
- - Password Password not same as last 5 passwords
- - Shorter Shorter password age for admin accounts
A 2.2.6 Session Fixation Protection:
Spring Security, enable session fixation protection:
| Code Block |
|---|
<http session-fixation-protection="newSession" |
...
>
|
A 2.2.7 Session tracking mode, JSESSIONID should only be stored in a cookie:
A 2.2.7.1 Configuration on the web.xml:
| Code Block |
|---|
<http session-fixation-protection="newSession" |
...
>
|
A 2.2.7.2 Programmatically:
| Code Block |
|---|
servletContext.setSessionTrackingModes(EnumSet.of(SessionTrackingMode.COOKIE)); |
...
|
Also, <tracking-mode> element also accepts the value for SSL which is to use SSL ids for session id.
A 2.2.8 Cookie flags:
A 2.2.8.1: Secure: ensures that the Cookie is only transmitted via SSL, configuration can be done via web.xml:
| Code Block |
|---|
<session-config> |
...
<cookie-config> |
...
<secure>true</secure> |
...
</cookie-config> |
...
</session- |
...
config>
|
Or programmatically:
| Code Block |
|---|
Cookie cookie = new Cookie("mycookie", "test"); |
...
Cookie.setSecure(true); |
...
|
A 2.2.8.2: HttpOnly: ensures that the Cookie cannot be accessed via client side scripts (i.e. JavaScript). Configuration can be done via web.xml:
| Code Block |
|---|
...
<session-config> |
...
<cookie-config> |
...
<http-only>true</http-only> |
...
</cookie-config> |
...
</session- |
...
config>
|
Or programmatically:
| Code Block |
|---|
Cookie cookie = new Cookie("mycookie", "test"); |
...
Cookie.setHttpOnly(true); |
...
|
A 2.2.8.3: Implement Content Security Policy
It's a browser side mechanism which allows you to create source whitelists for client side resources of your web application, e.g. JavaScript, CSS, images, etc. CSP via special HTTP header instructs the browser to only execute or render resources from those sources.
| Code Block |
|---|
Content-Security-Policy: default-src: 'self'; script-src: 'self' static.domain.tld |
References:
https://www.owasp.org/index.php/Authentication_Cheat_Sheet
https://technicalmumbojumbo.wordpress.com/2013/05/22/owasp-esapi-authenticator-tutorial/
https://www.owasp.org/index.php/Content_Security_Policy\\
A3 Cross-Site Scripting (XSS)
XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim's browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet