PCI scan in our servers recently failed due to cross-site scripting vulnerability in Magento 2 pages. They have requested like below to reproduce the issue.
REQUEST:
GET /2018-2019-random-url.html?<script>alert('TK00000031')</script> HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Host: example.com
Content-Type: text/html
Content-Length: 0
Evidence: <script>alert('TK00000031')</script>
But we couldn't reproduce it in any browsers. Only in IE it detects it's cross-site scripting and stops the execution of the page. Magento support also didn't help us and not sure how to fix it.
Does anyone faced the same issue and got the resolution?
Related
I have a codeigniter webapp being accessed through https.
Everything works as expected in Firefox, Safari, Chrome and Opera. When using Internet Explorer (V11), about half the time, I get a page saying:
This page can’t be displayed
•Make sure the web address https://... is correct
...
When I look at the Developer Tools (F12), I see that the last request has Result (Aborted)
Localhost:
URL/test.php Result / (Aborted) ......... Initiator / navigate
URL/test.php Result / 200 ......... Initiator / click
sometimes the first request succeeds (200) and the second line doesn't appear
Internet Host:
URL/test.php Result / (Aborted) ......... Initiator / navigate
I never get the Initiator/click line when connecting to this host.
If I hit enter in the browser bar (initiator/navigate), I get result (Aborted) every second time.
If I repeat (press enter in the address bar again) it succeeds/fails/succeeds
However if I click reload or press F5 (initiator/refresh) it works every time.
If I leave a couple of minutes between requests (of whatever kind) it also works every time
I thought this had something to do with the cache. I tried to add extra headers
Pragma:no-cache
Cache-Control: no-cache, must-revalidate
Expires: Mon, 26 Jul 1997 05:00:00 GMT
It seems the hosted server setup has some kind of default configuration that excludes my Pragma/Cache-Control/Expires lines, as these do not appear in the response headers when the pages are served from the internet, but do from localhost
IE is reporting a different User-Agent String when connecting to my hosted server on the internet compared to localhost
Localhost:
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.3; WOW64; Trident/7.0; .NET4.0E;
.NET4.0C; .NET CLR 3.5.30729; .NET CLR 2.0.50727; .NET CLR 3.0.30729;
AskTbFXTV5/5.9.1.14019)
Internet:
Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
Any clues greatly appreciated
TIA.
I finally had the idea of clearing the browsing history.
This happened by coincidence as I was working on some .css changes at the time and those changes didn't seem to get reflected when reloading the page.
I cleared Temporary Internet files, Cookies and History. I assume clearing Temporary Internet files is what cured the problem.
We are trying to access Google Maps over HTTPS.
We modified the script on the JSP to
script src="https://maps.googleapis.com/maps/api/js?client=<xxxx>&sensor=false" type="text/javascript"
This seems to work properly in Chrome and IE8. But in Firefox(V 19.0.2 and 11), there are some issues.
Specifically, We are getting
TypeError: google.maps.InfoWindow is not a constructor
in the Firefox console which I think means that the Google APIs are not getting accessed properly.
Any suggestions/solutions for this issue?
More:
We are getting a 407 response from googlemaps apis.
Specifically, using Fiddler the Request looks like:
CONNECT maps.googleapis.com:443 HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0
Proxy-Connection: keep-alive
Connection: keep-alive
Host: maps.googleapis.com
and the Response looks like:
HTTP/1.1 407 Proxy Authorization Required
Date: Mon, 22 Apr 2013 04:46:47 GMT
Proxy-Connection: keep-alive
Via: 1.1 XXXXX
Cache-Control: no-store
Content-Type: text/html
Content-Language: en
Proxy-Authenticate: NTLM
Proxy-Authenticate: Basic realm="Websense Content Gateway"
Content-Length: 322
Proxy-Support: Session-Based-Authentication
<HEAD><TITLE>Proxy Authorization Required</TITLE></HEAD>
<BODY BGCOLOR="white" FGCOLOR="black"><H1>Proxy Authorization Required</H1><HR>
<FONT FACE="Helvetica,Arial"><B>
Description: Authorization is required for access to this proxy</B></FONT>
<HR>
<!-- default "Proxy Authorization Required" response (407) -->
</BODY>
Damn.. Its an issue with my company's internet proxy!! I had to add an exception to all the URLs used by my application(including google map apis) and it works fine.
Add all urls of google map api over https in Location input bar for certificate exceptions.
for example:
https://maps.googleapis.com
https://maps.gstatic.com
'Get Certificate' then 'Confirm Security Exception'
Tools > Advanced > Certificates > View Certificates > 'Servers' Tab > 'Add Exception...'
I'm calling a server site on our internal server. This domain looks like this:
http://server.domain:12345/x.html
Now, with IE this works just fine, I'm getting the data. (My problem there is that IE caches the website after the first call forever, but never mind).
Now, if I'm trying to do exactly the same in Firefox, it won't work, the same in Google Chrome.
Firebug says this:
Answer-Header
Connection Keep-Alive
Content-Length 109
Content-Type text/html; charset=UTF-8
Keep-Alive timeout=5000
Server AbWeb Version SRSG 1.34
Set-Cookie sessionkey=80da7dfe-1c9c-4460-9592-3ce55cecb379
Request-Header
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Accept-Encoding gzip, deflate
Accept-Language de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Connection keep-alive
Host server.domain:12345
Origin http://otherserver.domain
Referer http://otherserver.domain/test/
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0
Chrome says this:
X XMLHttpRequest cannot load http://server.domain:12345/x.html. Origin http://otherservere.domain is not allowed by Access-Control-Allow-Origin.
server.domain:12345/x.html
X Failed to load resource
It seems you perform cross-domain JavaScript calls. The target server must set the Access-Control-Allow-Origin HTTP header. In your case the server http://server.domain must set a header like:
Access-Control-Allow-Origin: http://otherserver.domain
I do not know why it works for IE, it may have to do with your security domains as your just working in the intranet.
See another example:
Jquery form doesn't show submission message on web server but it shows submission message on local host
I have an Spring application (with Spring Security and Spring MVC) deployed in a Tomcat server. The application works perfecty in Firefox, Chrome, Opera and IE9.
I have a weird problem with IE8. The login screen loads, and (as I can see in server logs) the session is open when username and password are provided. Once the user is logged, and the browser is redirected to the main page, a 404 error is returned by the server.
As IE8 developer tools doesn't have a net panel, I have used Fiddler to monitor http connections. I thought that it could be happening that it was doing a wrong request during page loading but it was the main page request wich is responsing with 404.
How is it possible that the server responses with 404 to the main page request just only in IE8?
Thank you.
Edited:
Those are the request header for IE8 and Firefox respectively:
GET /myWebApp/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: es-ES
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; Tablet PC 2.0; .NET4.0C; .NET4.0E)
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
Host: dev.mydomain.com
Connection: Keep-Alive
Cookie: JSESSIONID=ABA1382304002F894ABDFCC2442FA5F8; SPRING_SECURITY_REMEMBER_ME_COOKIE=NGUxMTZlOTY3OGM0OTgxNDY4NDczOTlkOjEzMjQ1ODMwMzU0MDI6OWZiYzdhYjY1ODY2Mzc3YmI0Yzc5YTMzMWI5NDhjNTg
--
GET /myWebApp/ HTTP/1.1
Host: dev.mydomain.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es-es,chrome://global/locale/intl.properties;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Cookie: JSESSIONID=7FD3B02252E2FCBC9BE7249AFD84F541; SPRING_SECURITY_REMEMBER_ME_COOKIE=NGUxMmYxMTgzMmRjZTM0NzYyMWVjOWEwOjEzMjQ1ODMwMTA1MTU6MzFiYzU4OGQ4NTMwN2Y3M2I4YmQzN2M0NzY2MzcwZjI
Knowing that the problem was about "Accept" I have revised the MVC Controller classes mappings and I have finaly found the issue. Somehow this was the way that the main page was mapped in MVC so it didn't work whith the IE8 header attribute:
#RequestMapping( value = "/", headers = "Accept=text/*" )
I have learned a hard lesson today. ;-)
Say, there's a URL, http://www.example.com/#hello.
Will the #hello thing be sent to the web server or not, according to standards?
How do modern browsers act?
The answer to this question is similar to the answers for Retrieving anchor link in URL for ASP.NET.
Basically, according to the standard at RFC 1808 - Relative Uniform Resource Locators (see Section 2.4.1), it says:
"Note that the fragment identifier is not considered part of the URL."
As stephbu pointed out, "the anchor tag is never sent as part of the HTTP request by any browser. It is only interpreted locally within the browser".
The hash variables aren't sent to the web server at all.
For instance, a request to http://www.whatismyip.org/#test from Firefox sends the follow HTTP request packet
GET / HTTP/1.1
Host: www.whatismyip.org
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cache-Control: max-age=0
You'll notice the # is nowhere to be found.
Pages you see using # as a form of navigation are doing so through javascript.
This parameter is accessible though the window.location.hash variable
The anchor part (after the #) is not sent to any $_SERVER variables in PHP. I don't know if there is a way of retrieving that piece of info from the URL or not (as far as I know, it's not possible). It's supposed to be used by the browser only to find a location in the page, which is why the page does not reload if you click on an anchor like so: hello