So I found an old http page of a shopping website that doesn't have any filtering occurring. Using a proxy, I can inject whatever I want into the page, and it reflects in the application's response. If I load the same request in a browser, I get redirected to their HTTPS site. Is there any possibility of having XSS occur before the redirect happens? Or is the Javascript after the server side redirect, therefore is the reason why my payload isn't executing? I'm using a simple alert(1) which is reflected in the response on the http site, but not on the https page.
it depends on the sort or redirection, When the server redirects you, the Browser wont execute javascript code.
If its a Client side redirection with javascript your code should be executed.
Related
I am trying to make use of functional url in case of mono lambda function, I have created a functional url with no security.
URL was created successfully, but Not able to hit that url using postman. So I use chrome web browser to hit my url(Get request). But the problem was whenever I hit the url, My function gets executed twice.
If anyone have faced same issue, Please assist.
There are two possibilities I can think off-
Chrome/browser sending another request for favicon.png
If you have configuration on server side that enforce HTTP to HTTPS conversion of the request, like re-direct to enforce SSL connection. In that case as well, browser send one request HTTP and redirect request to HTTPS. e.g when you hit- http://example.org, if it enforce the https, then again browser send another request to https://example.org.
You need to check possibilities here using network trouble shooting. Hope this will help you!
TLDR: React app's API calls are returning with status code 200 but without body in response, happens only when accessing the web app from some browsers.
I have a React + Django application deployed using nginx and uwsgi on a single centOS7 VM.
The React app is served by nginx on the domain, and when users log in on the javascript app, REST API requests are made to the same nginx on a sub domain (ie: backend.mydomain.com), for things like validate token and fetch data.
This works on all recent version of Firefox, Chrome, Safari, and Edge. However, some users have complained that they could not log in from their work network. They can visit the site, so obviously the javascript application is served to them, but when they log in, all of the requests come back with status 200, except the response has an empty body. (and the log in requires few pieces of information to be sent back with the log in response to work).
For example, when I log in from where I am, I would get response with status=200, and a json object with few parameters in the body of the response.
But when one of the users showed me the same from their browser, they get Status=200 back, but the Response is empty. They are using the same version of browsers as I have. They tried both Firefox and Chrome with the same behaviours.
After finally getting hold of one of the user to send me some screenshots. I found the problem. In my browser that works with the site, the API calls to the backend had Referrer Policy set to strict-origin-when-cross-origin in the Headers. However on their browser, the same was showing up as no-referrer-when-downgrade.
I had not explicitly set the referrer policy so the browsers were using each of their default values, and it differed between different versions of browsers (https://developers.google.com/web/updates/2020/07/referrer-policy-new-chrome-default)
To fix this, I added add_header 'Referrer-Policy' 'strict-origin-when-cross-origin'; to the nginx.conf file and restarted the server. More details here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy
The users who had trouble before can now access the site API resources after clearing cache in their browsers.
I want to know when I'm using IE8 open a website (like www.yahoo.com), which API will be called by IE8? so I can hook these API to capture which website that IE8 opening currently.
When you enter a URL into the browser, the browser (usually) makes an HTTP request to the server identified by the URL. To make the request, the IP address of the server is required, which is obtained by a DNS lookup of the host (domain) name.
Once the response -- usually containing HTML markup -- is received, the browser renders it to display the webpage.
More details available here: what happens when you type in a URL in browser
So, in the general case, no "API" request as such is made. (Technically speaking, you can think of the original HTTP request to the server as an API request). The sort of "API" request you presumably mean, however, is not made in this general case just described. Those requests happens when the JavaScript executing on the page makes an Ajax HTTP request (XmlHttpRequest) to the web server to carry out some operation.
I am not sure about IE8, but the "developer tools" feature of most modern browsers (including IE9 and IE10), would let you see the Ajax HTTP requests that the webpage made as it carried out different operations.
Hope this helps.
IE uses Microsoft's WinSock library API to interact with web servers.
You may want to look for a network monitoring/sniffing API, which you could use to examine HTTP requests, and determine the URLs the browser is using.
I'm writing a small content server as a web service. There are 2 units - one authenticates the application requesting content and when authentication succeeds, the request is forwarded to the other unit that serves the content.
[1] If I want to do this using CGI
scripts, is there any equivalent of
jsp:forward in CGI?
[2] Suppose if
forwarding is not possible, the
client application shouldn't be able
to request the second unit directly.
What is the proper way to do this?
Another attempt, since you are not after HTTP redirect...
The short answer is: Yes, it is possible.
However, it is highly dependent on the tools you are using. What web server and CGI scripting language you are using?
CGI scripts can do practically anything they want to do, for example they could execute code from other CGI scripts. Thus, they can provide the behavior you are looking for.
CGI (Common Gateway Interface) just describes how a web server starts a CGI script and gives the script input data via environment variables. CGI also describes how the script returns data to web server. That's all.
So if your authorization script wants to delegate some operation to other some script, it is up to that authorization script to implement it somehow. The CGI protocol does not help here.
The concept you might be looking for is called HTTP redirect, where the server sends a response to browser's request, telling the browser to fetch a new page from another URL.
CGI can do HTTP redirects just fine just like jsp:forward. You need just to output the right HTTP headers.
You need to return a 302 response code in HTTP headers, and provide location URL where browser should go next. Have your CGI script output these kind of headers:
HTTP/1.1 302 Redirect
Location: http://www.example.org/
These headers tell browser to fetch a page from URL http://www.example.org/ .
I am grabbing a webpage with WinHttp and the resulting page is the site's 404 file not found page. I know that the code works as I have tested it with other websites. The page in question is a normal http protocol and .html file.
What can I do?
You don't give a whole lot to go on. I'd probably start with a trace of the HTTP session from your WinHttp calls and compare it with a trace from a working browser-based session and see what's different. Could be anything from a cookie to a referer field to who-knows-what that the server might not like.