I'm inspecting web page and using Burp suite to intercept HTTP requests made by JS.
For certain URL I receive 403 status and Claudflare's page with message "Please turn JavaScript on and reload the page".
JS is turned on in my browser (Firefox) and that URL works fine with disabled proxy.
How Cloudflare detects Burp and how to bypass it?
In my case I was able to fool Cloudflare simply by overriding the default User-Agent header that Burspsuite uses. Go to Proxy > Options > Match and Replace then add and enable a Request header rule that overrides the User-Agent header:
Match
Replace
^User-Agent.*$
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:105.0) Gecko/20100101 Firefox/105.0
Related
I have an API built on CakePHP. It works for the most part but every once in a while browser access to the API dies. The error message on the XHR request response is:
'Access to XMLHttpRequest at 'http://be:8888/api/pings' from origin 'http://localhost:8080' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
However if I make exactly the same request via POSTMAN (or if I browse directly to the URL, rather than via XHR) it works without any trouble. I thought it might be a pre-flight OPTIONS issue but the request headers don't list a Request Method and the Apache access log shows these to be GET requests. There's nothing related in the Apache error log.
Restarting MAMP – i.e. Apache – does not fix the issue, nor does flushing the local DNS cache. The only thing that fixes it is a restart, after which it all works fine again for a few hours before eventually going on the blink again.
I can't think of what's causing this. I don't think it's a true CORS middleware error because the restart fixes it and the API is accessible normally. Also if I put a die in during the CORS middleware __invoke method it doesn't get that far (the die in the webroot index should be hit first anyway).
I get this error even if I disable the app by putting die('here'); at the start of the webroot index.php file.
Even if I delete the index.php files (both in the project root and webroot) so that browsing to the URL shows Apache's default error 404 not found: The requested URL /webroot/index.php was not found on this server, I still get the CORS errors when trying via XHR in the browser.
I've only noticed this issue since upgrading to Mac OS X Catalina.
What could be causing this?
[Update:]
Here's proof that it is working in the browser after a system restart:
Summary
URL: http://be:8888/api/clients
Status: 200 OK
Source: Network
Address: ::1.8888
Request
GET /api/clients HTTP/1.1
Accept: application/vnd.api+json
Content-Type: application/vnd.api+json
Origin: http://localhost:8080
Accept-Language: en-gb
Access-Control-Allow-Origin: *
Host: be:8888
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_3) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.5 Safari/605.1.15
Referer: http://localhost:8080/
Accept-Encoding: gzip, deflate
Connection: keep-alive
However, after a few hours it stops working. If it was actually a CORS issue my understanding is that it would NEVER work.
I'm not an Apache/PHP professional, but make sure you query HTTPS via HTTPS and http via http, other words, both sides should be same. Also, check the request header. And add "access-control-origin" in request header.
My Google compute engine virtual machine is hosting apache which is serving my website. When my website sends a post request to http://localhost:8080 It returns a 404, even though the (golang) server running in the file over can see url get requests.
I've tried adding Apache proxy all / calls to that server, But this seems to only work on Get requests put into the url.
To show that my server can see GET requests
[negroni] 2019/10/23 08:29:27.048676 Started GET /api/v1/login
[negroni] 2019/10/23 08:29:27.048941 Completed 404 Not Found in 262.947µs
While i need to be able to have it see the POST request
(axios.post('/api/v1/login', {username, password}))
Full request looks like
http://localhost:8992/api/v1/login
Here is the 'General' section of chrome Devtools Network
Request URL: http://localhost:8992/api/v1/login
Referrer Policy: no-referrer-when-downgrade
Here are the Request Headers
Provisional headers are shown
Access-Control-Request-Headers: content-type
Access-Control-Request-Method: POST
DNT: 1
Origin: https://carterstestdomain.store
Sec-Fetch-Mode: cors
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36
Any help is greatly appreciated.
Fixed this by following
Apache and Node.js on the Same Server
Also, As with me, The problem could be comming from the request being http instead of https :)
We are seeing random letters appear in access logs. The requests 404 since the content does not exist. The requests are made by a variety of users and other requests from the same ip usually look genuine. There is no way to request these from the site. Some of these requests even appear from internal traffic on our network.
Example:
157.203.177.191 - - [04/Feb/2018:23:51:20 +0000] "GET /VLTRP/content/dam/example/dotcom/images/ABtest/existing-customer-thumb.jpg HTTP/1.1" 404 60294 39082 "http://www.example.com/shop.html" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0" 2
Without the /VLTRP this is a genuine request. Has anyone seen something similar before?
For info we are running Apache/2.2.15 (Unix) with ModSec enabled. We do see similar behaviour on another site where we do not have ModSec configured. We see similar requests for internal, external and bot traffic.
I've got a Laravel 5.4 API, that works fine in Postman and the Browser. Localhost works fine- Laravel 5.4 is running on one port, and Vue in hot deploy mode is running fine.
However, when I move the Vue code to my production server I get this error:
Response for preflight is invalid (redirect)
In Chrome Developer Tools, the network tab shows this:
General
Request URL:http://backend-dev.xolas.io/api/v1/view/calendar/-30/90/
Request Method:OPTIONS
Status Code:301 Moved Permanently
Remote Address:217.182.66.247:80
Referrer Policy:no-referrer-when-downgrade
Response Headers
Connection:Keep-Alive
Content-Length:349
Content-Type:text/html; charset=iso-8859-1
Date:Mon, 10 Jul 2017 13:40:08 GMT
Keep-Alive:timeout=5, max=100
Location:http://backend-dev.xolas.io/api/v1/view/calendar/-30/90
Server:Apache/2.4.25 (Ubuntu)
Origin Headers
Accept:*/*
Accept-Encoding:gzip, deflate
Accept-Language:en-US,en;q=0.8
Access-Control-Request-Headers:access-control-allow-origin,authorization
Access-Control-Request-Method:GET
Connection:keep-alive
Host:backend-dev.xolas.io
Origin:http://localhost:8080
Referer:http://localhost:8080/
User-Agent:Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.109 Mobile Safari/537.36
I've installed a CORS plugin on Laravel, still no joy.
My axios config is as follows:
axios.defaults.headers.common['Authorization'] = store.apiKey
axios.defaults.headers.get['Content-Type'] = 'application/json;charset=utf-8'
axios.defaults.headers.post['Content-Type'] = 'application/json;charset=utf-8'
axios.defaults.headers.common['Access-Control-Allow-Origin'] = 'https://' + store.endpoint + ', http://' + store.endpoint
Endpoint is Larvel API server, which works fine.
Any clues would help, since I'm at a loss on how to resolve this. Thanks in advance.
The server is is sending a redirect from:
http://backend-dev.xolas.io/api/v1/view/calendar/-30/90/
to:
http://backend-dev.xolas.io/api/v1/view/calendar/-30/90
Removing the trailing '/' in your request should prevent the 301. (Although that url is responding with a 500 Server Error.
Your browser’s sending a CORS preflight OPTIONS request before trying whatever request it is that your code’s actually trying to send itself, and then your Laravel backend is responding to that OPTIONS request with a 301 Moved Permanently redirect.
The server must respond to the OPTIONS preflight with a 2xx status — typically 200 or 204.
If the server doesn’t do that, the preflight fails and the browser never tries the actual request.
So you must change your Laravel backend to respond to that OPTIONS with a 200 or 204.
And the browser does a preflight to begin with because your request adds Authorization and Content-Type: application/json;charset=utf-8 & Access-Control-Allow-Origin headers.
You should remove the code that’s adding the Access-Control-Allow-Origin there, because that’s a response header and there’s never any need to send it in a request. But assuming you need the Authorization and Content-Type headers in the request in order for it to actually work as expected with your backend, then there’s no way you can avoid the browser preflight.
So you really must configure your Laravel backend to respond to OPTIONS with a 2xx success.
We have a servlet hosted on jboss which works on HttpServletRequest. But sometimes we receieve requests that do not get decoded by jboss, and when we do getQueryParam on HttpServletRequest, we get null. The jboss access log shows the url in encoded form. Normally, when everything works smooth, url is shown decoded in access log.
e.g.:
This was a problematic request:
127.0.0.1 [13/Apr/2009:14:18:53 +0000] GET /redirectService//%3Fclient_id=3&redirect_url=http%253A%252F%252Fwww.amazon.de%252Fgp%252Fsearch%253Fie%253DUTF8%2526keywords%253DMicrosoft+Office+2007%2526search-alias%253Dsoftware%2526 HTTP/1.1 'null' 'Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12)'
This was a proper request:
127.0.0.1 [13/Apr/2009:14:19:37 +0000] GET /redirectService//?client_id=3&redirect_url=http%3A%2F%2Fwww.amazon.de%2Fgp%2Fsearch%3Fie%3DUTF8%26keywords%3DMAGIX+Video+deluxe+2008%26search-alias%3Dsoftware%26 HTTP/1.1 'http://www.google.de/search?hl=de&q=magix+video+deluxe+2008&meta=&aq=3&oq=%22magix%22' 'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; .NET CLR 1.1.4322)'
Could we be missing some jboss decode settings, or is it just a case of malicious user?
Hard to tell, really.
The client seems to be decoding the question mark into "%3F" but not the ampersand. Suspicious, isn't it?. This looks like a buggy client IMO. Maybe nonportable javascript, maybe some URL-rewriting bug on the web server side, or a more esoteric cause ... a malfunctioning browser plugin.
To rule out nonportable javascript, log the user-agent and compare results. To rule out url-rewriting bug, log referer.
AFAIK, the URL decoder behavior is hardcoded. The string encoding can change if uri's get written in non-ascii or non-iso88591, but that's not what you're after. What encodes question marks but fail to encode ampersands escapes me.
We logged the user-agent, it is some suspicious "XXXagentXXX" in most cases, but a genuine Mozilla (as above) in others. Referrer is "-" for all these requests. However, there is one curious thing I noticed today. We redirect our requests from apache (80) to jboss. Apache access log shows above request as completely encoded:
GET /r/%3Fclient_id%3D3%26redirect_url%3Dhttp%253A%252F%252Fwww.amazon.de%252Fgp%252Fsearch%253Fie%253DUTF8%2526keywords%253DCyberlink%2BPower%2BDirector%2526search-alias%253Dsoftware HTTP/1.0" 400 965 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.10)"
while jboss access log has everything except %3F decoded. Now this makes me think apache is screwing up somewhere in the decoding?
I had problem decoding URL too with JBoss 13.
I added the last line in JBoss configuration and it works now.
/subsystem=undertow/servlet-container=default:write-attribute(name=default-encoding,value="ISO-8859-15")
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=url-charset,value="ISO-8859-15")
Doc is here if more needed : https://wildscribe.github.io/WildFly/13.0/subsystem/undertow/server/http-listener/index.html