Quantcast
Channel: URL Rewrite Module
Viewing all articles
Browse latest Browse all 2482

Reverse proxy with ARR and URL Rewrite Module throws 403 error

$
0
0

Our environment is set up as shown  below.
Browser<----https-->IIS(with ARR and URLRewrite) <------http----->WAS (WebSphere)

We moved the URL Rewrite rules from dev server to test server and on test environment, have been getting 403 error.

Fiddler log:

HTTP/1.1 403 Forbidden
Content-Type: text/html
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Mon, 16 Jan 2017 19:23:07 GMT
Content-Length: 1245

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
<title>404 - File or directory not found.</title>
<style type="text/css">
</style>
</head>
<body>
<div id="header"><h1>Server Error</h1></div>
<div id="content">
 <div class="content-container"><fieldset>
  <h2>404 - File or directory not found.</h2>
  <h3>The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.</h3>
 </fieldset></div>
</div>
</body>
</html>

Went deeper into it, FTR didn't log 403's and our IIS admin found that UrlScan module is the root cause for the problem. It's restricting lengthy URLs.

URL failed:

note: I masked the url,  but that's the structure and it's 863 characters long.

/TestWeb/toWASFW/prweb/Servelt1/ZsvSk3vV8PtgJEa4_x3fiQ%5B%5B*/!MyWebApp/$STANDARD/webwb/xxxx_desktop_domainsuffix_1819019784.js!xxxx_13833664524!desktopwrapper_12997951049!automationscripts_1864420987!

_ui_jquery_1796787788!desktopwrapper_12997951049!automationscripts_1864420987!

_ui_jquery_1796787788!desktopwrapper_12997951049!automationscripts_1864420987!

_ui_jquery_1796787788!

UrlScan log:

2017-01-16 19:23:07 xxx.xx.xxx.xx 1 GET /testWeb/toWAS/prweb/Servelt1/ZsvSk3vV8PtgJEa4_x3fiQ%5B%5B*/!MyWebApp/$STANDARD/webwb/xxxx_desktop_domainsuffix_1819019784.js!xxxxx_yui_13833664524!desktopwrapper_12997951049!
automationscripts_1864420987!ui_jquery_1796787788!desktopwrapper_12997951049!desktopwrapper_12997951049!desktopwrapper_12997951049!desktopwrapper_12997951049! Rejected URL+too+long URL 680 260

IISlog:

2017-01-16 19:24:09 xxx.xxxx GET /Rejected-By-UrlScan ~/testWeb/toWAS/prweb/Servelt1/ZsvSk3vV8PtgJEa4_x3fiQ%5B%5B*/!MyWebApp/$STANDARD/webwb/xxxx_desktop_domainsuffix_1819019784.js!xxxxx_yui_13833664524!desktopwrapper_12997951049!
automationscripts_1864420987!ui_jquery_1796787788!desktopwrapper_12997951049!desktopwrapper_12997951049!desktopwrapper_12997951049!desktopwrapper_12997951049!  443

We updated UrlSegmentMaxLength  registry to  get around with http api restriction and now stuck at UrlScan module. I've been searching around and found that UrlScan restrictions are available at two places, 

1) at UrlScan.ini file which accepts value in bytes(MaxUrl default 260)

https://www.iis.net/learn/extensions/working-with-urlscan/urlscan-3-reference#RequestLimitsSection

2)  there is a section in web.config file <requestLimits> that accepts maxUrl value in bytes (default 4096)

system.webServer
security
requestFiltering
requestLimits

https://www.iis.net/learn/extensions/working-with-urlscan/urlscan-3-reference#RequestLimitsSection

Which one is latest and for fixing 403 error, what is the appropriate place to change ?

To me <requestLimits> looks  like a flexible place since it can stay at my application level. But if you have UrlScan.ini existing already at server level, would updating<requestLimits> in my application's web.config file take precedence and allow lengthy URL ?

Also, I have been reading more and more about it and it appears that most of the UrlScan features are incorporated into IIS's Request Filtering module, if that's the case, why there is a huge difference in default values,  260 vs 4096 bytes, for MaxUrl ?

PS: I questioned our application team at WAS end, why the URL  is so long and is there a way to reduce it. But until I receive a reply from them, I'm thinking of going with IIS configuration update.

Thanks for your help!


Viewing all articles
Browse latest Browse all 2482

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>