Rules are good. Everyone should follow the rules. Generally, anyway, except for when $your_favorite_excuse. Today, I tried to short cut the login process in order to save a few seconds (yes, I’m that lazy) but my rule enforcing Web App Firewall put the smack down on me..
In my WAF, I have the option to define pages that should only be accessible after authenticating. This keeps people from taking advantage of pages that don’t even know they are sensitive. Because this feature requires tracking the success of a login, a login page must be configured, as well as some basic things about the page (form id’s for usernames and passwords, for instance). If someone tries to access a sensitive page without traversing the login page first, blocking ensues and people get sad. Below is an example of a request (modified slightly) that I was caught using..
GET /w/wp-admin.php HTTP/1.1 Host: www.planetspork.com Origin: https://www.planetspork.com Cookie: BIGipServerHosting.app~Hosting_pool=532589261.20480.0000; F5_ST=1z1z1z1415495768z604800; TS0194a582=0150caffc4252c44462a465f6b835bcc722802af1863ff0b91c54dbcbc7dfd00c0a65088177d2dae183469a1010d94fbe5fcc15c8b8f9c36606d78ecf4c8051191c76f399f; LastMRH_Session=31b6632b Connection: keep-alive Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/600.1.17 (KHTML, like Gecko) Version/7.1 Safari/537.85.10 Accept-Language: en-us Referer: https://www.planetspork.com/my.policy X-Forwarded-For: 18.104.22.168 X_FORWARDED_PROTO: https session-id: 31b6632b session-key: 00000000000000000000000000000000 username: bimhoff
In my policy, /w/wp-admin.php is part of the “sensitive” list and /w/wp-login.php is the login page. As mentioned before, the wp-login.php MUST be hit first before going to /w/wp-admin.php. It’s the rule. Doing it backwards means you’re doing it wrong. I did it wrong and was I blocked. 🙁
For the super observant folks that noticed a username and the LastMRH cookie as part of the request, it’s probably worth mentioning that I’m using Access Policy Manager (APM) as part of my setup. Without APM, going right at /w/wp-admin.php would have blocked before anyone had a chance to enter credentials. In this case, wp-admin.php is also protected by APM, which means APM has first crack at hitting up users for credentials. Because my credentials were valid, APM used a single sign on (SSO) policy to pass credentials on to WordPress which saves me valuable seconds and ensures I don’t have to type credentials twice. (I told you, I am lazy.)