Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Quick Testing of Deployment
We have StateWall loaded on login.example.com. Let's do a quick test. If we send a request to http://login.example.com, we get the following page back, as shown in Figure 8.
)
Figure 8 Login page for an application.
This page asks the user for login credentials. Try to access /mails/ without a valid session. The request is captured by StateWall. Because session information is missing in the request, the request is blocked and an error message is sent back to the user, as shown in Figure 9.
)
Figure 9 Trapping unauthorized access.
Any session-based attack is blocked at the Web application level firewall because its state is being maintained by checking with the session object at the firewall. Now let's use the authentication credentials—"john" as user and "smith" as password—as shown in Figure 10.
)
Figure 10 Logging in to the application with authentication credentials.
We receive the following response, as shown in Figure 11.
)
Figure 11 Successful login to the application.
The login is successful, and a session name login is created on the application. If we try to access /mails after this successful authentication, we receive the following response in the browser (see Figure 12).
)
Figure 12 Access to the /mails/ module of the application using a session.
We have StateWall that can now track sessions and make decisions for each incoming request. We can ensure that all session and application variables are cleaned up for logged-out users by sending a request to logout.aspx, as shown in Figure 13.
)
Figure 13 Logging out of the application and cleaning up session variables.
This is just one attack vector use can use to defend and protect sessions. There are many other vectors that can be blocked by expanding StateWall.