By Philippe Céry.
In a web application with different user roles, authentication is not enough. Each request must be controlled against user’s role to ensure the user is authorized to use the requested function or access the requested page.
Moreover, functions available in that account management section for clerks are not controlled either. The attacker can then transfer money to his own account. And hopefully, the attacker’s actions are not logged.
You need to be sure access to all pages and functions requiring authentication and specific authorization is controlled. To simplify and enforce security, your access control mechanism should be centralized and role-based. It is also highly recommended to always apply a “deny-by-default” rule, i.e. explicitly define what is allowed and disallow everything else.
You can use standard java filters to achieve this goal. Some third-party frameworks also provide API for centralized and role-based authentication and access control.
You need to first identify the different roles available on your web site. E.g. you can have the simple USER role for authenticated users with no additional rights, the MANAGER role to manage users and the ADMIN role with administration privileges.
When possible, organize your website according to these roles:
home.xhtml login.xhtml access_denied.xhtml /secure |_ home.xhtml |_ /user |_ accounts.xhtml |_ account_details.xhtml |_ contact_my_clerk.xhtml |_ ... |_ /mgmt |_ users.xhtml |_ messages.xhtml |_ ... |_ /admin |_ managers.xhtml |_ monitoring.xhtml |_ ...
Then, you have to properly configure your preferred session management framework.
If the requested URL requires authentication, the framework should redirect unauthenticated users to the login page. If the requested URL requires a specific role, the framework should redirect to an “access denied” error page.
With Spring Security, the configuration should look like the following:
<sec:http auto-config="true" access-denied-page="/access_denied.xhtml"> <sec:form-login login-page="/login.xhtml" default-target-url="/secure/home.xhtml" /> <sec:intercept-url pattern="/login.xhtml*" access="IS_AUTHENTICATED_ANONYMOUSLY" /> <sec:intercept-url pattern="/secure/user/**" access="ROLE_USER,ROLE_MANAGER" /> <sec:intercept-url pattern="/secure/mgmt/**" access="ROLE_MANAGER" /> <sec:intercept-url pattern="/secure/admin/**" access="ROLE_ADMIN" /> <sec:intercept-url pattern="/secure/**" access="ROLE_USER,ROLE_MANAGER,ROLE_ADMIN" /> <sec:session-management invalid-session-url="/login.xhtml" /> </sec:http>
Hide unauthorized functions
If users don’t know a function exists, they won’t be tempted to use it.
With your preferred web framework, you will find different mechanisms to display or hide an HTML block depending on the user’s privileges.
E.g. Spring Webflow provides
<authorize>, a Spring Security tag for JSF:
<security:authorize ifAnyGranted="ROLE_USER,ROLE_MANAGER" ifNotGranted="ROLE_ADMIN"> <em>Links to client functions (also accessible to clerks)</em> </security:authorize> <security:authorize ifAllGranted="ROLE_MANAGER" ifNotGranted="ROLE_USER,ROLE_ADMIN"> <em>Links to Management functions (only for clerks)</em> </security:authorize> <security:authorize ifAllGranted="ROLE_ADMIN" ifNotGranted="ROLE_USER,ROLE_MANAGER"> <em>Links to Administration functions (only for administrators)</em> </security:authorize>
Log sensitive actions
Last but not least: log in a secure place all sensitive actions done on your website. If your website is attacked, even if the attack failed (because the mitigations I proposed are all applied on your website), it is still interesting to know how and when you were attacked and by who. Thus, you can’t take specific actions against the source of the attack (blocking IP, deactivating account, revoking client certificate…) and investigate further.
An even better option would be to be alerted when a suspicious action is requested. For example, if an authenticated simple user tries to access a management function, of course, the access will be rejected but it may be interesting to know that there was a potential attack attempt.
To see all articles related to OWASP Top 10, follow the tag #owasp