Anthony Galiamov

View Original

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.

See this content in the original post

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.

See this content in the original post

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.

See this content in the original post