Blocking Internet Explorer - HTTP XSLT
Browser User Agent Checking - Internet Explorer
When Microsoft released Internet Explorer, it blew everyone’s socks right off. Developers finally had a browser that supported CSS, was incredibly fast, supported dynamic HTML, was available cross-platform and even introduced Java and applets to the world. It even had 95 percent market share by 2003.
But that has all changed over the years.
It’s now 3.5 times slower than modern browsers, it’s barely being supported by Microsoft and will be end-of-life by 2025, it doesn’t support modern JavaScript or CSS standards and the worst part, just having Internet Explorer on your computer at all can expose you to security threats. Not fun!
So, how do we block it from being used?
A useful link to start with is: How to check the user is using Internet Explorer
Writing our XSLT Rule
Here’s an example looking for Trident
in the user-agent
HTTP request header. If the test is successful, we’ll return a location
header in the response to the browser, directing it to redirect to a error page we’ve hosted. If Trident
isn’t found in the header, the request will be passed onto the server to respond.
Testing you XSLT rule
You can test your HTTP XSL Transformation rule using this online tool: XSLT Test
Here’s a sample request you can use. Feel free to change it up if needed.
Attaching the rule to the request - ACL
In IBM Security Access Manager (ISAM), go to your web settings, select reverse proxy, select your instance and in the reverse proxy configuration file, you can now apply a transformation rule using URL matching as shown below.
Just remember to have added your XSLT rule to HTTP Transformations and deployed your changes. You kind of need to have something to attach to your WebSEAL instance.