InformAction Forums

I'm running into a XSS redirection problem when I try to login to a local cafe. When I launch Firefox 3.0.10 my homepage is redirected to the cafe's (SonicWall) login screen. However because NoScript has sanitized it I can enter the login but I can't get past the login screen. If I turn off Advanced XSS filtering it works OK and after entering my login info I am redirected to my homepage.

Here is the log entry:

[NoScript XSS]
Sanitized suspicious request.
Original URL [http://10.10.10.10/peets/default.asp?ss ... rce%3Diglk] requested from [http://172.16.31.1/externalGuestRedirec ... rectPage=0].
Sanitized URL: [http://10.10.10.10/peets/default.asp?ss ... rce%3Diglk].

I'm not that good with Regex and I need some help sorting this out! Also, do I need to whitelist both of these private IP's to make this work? I have the 10 network whitelisted already.

Thanks!

(Just to point out that both 10.*.*.* & (a good portion of & including that listed above) 172.*.*.* are non-routable IPs.)

Yes but if they are on an intranet or however configured to work, regex filter for the XSS on the patter could allow the OP to still use the function. I don't think routability is an issue here but I could be wrong.

This is a false positive and will be fixed.
In the meanwhile, just add the following line to your XSS exceptions box: Good luck and let me know.

My guess is that they are using a combination WiFi / firewall appliance. The login is in the DMZ which allows them to redirect for authentication which is coming from a central source. The way it works from the customers perspective is that you request a Internet access with your order and are given a receipt with a four digit code. Boot your system, obtain an IP address from their DHCP and launch your browser. The browser is redirected the appliances DMZ which hosts an authentication page where the four digit code is entered. Upon a positive authentication the next screen offers you a link to your original destination homepage.

Under normal circumstances it is one of the more efficient systems I've run across.

GµårÐïåñ wrote:Yes but if they are on an intranet or however configured to work, regex filter for the XSS on the patter could allow the OP to still use the function. I don't think routability is an issue here but I could be wrong.

Giorgio Maone wrote:This is a false positive and will be fixed.

Oh, I hate it when that happens!

Giorgio Maone wrote:In the meanwhile, just add the following line to your XSS exceptions box:

Code: Select all

^http://10\.10\.10\.10/[^<'"]+$

Good luck and let me know.

Thank you very much! I appreciate you taking the time to help me!

I added the snippet and it works perfectly! Thanks again!!