I've tried to brute-force a web page that is running behind a reverse proxy. All I have is the username (given) and for passwords -> One of the common passwords in 2022.
When I try to run burp suite, I was unable to even capture the login credentials, this is what I got.
"
GET /main/ HTTP/2
Host: landing.agitated-banzai.xyz
Cache-Control: max-age=0
Authorization: Digest username="duriansandwich", realm="Restricted area", nonce="63ddc119985ff", uri="/main/", response="5da387c460fb0fd84cfd9f599cb198fe", opaque="cdce8a5c95a1427d74df7acbf41c9ce0", qop=auth, nc=00000002, cnonce="aa2dc7750a67681d"
Sec-Ch-Ua: "Chromium";v="105", "Not)A;Brand";v="8"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Linux"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.5195.102 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
"
What is the way about going to solve this?
Related
First URL is presigned. Then with PUT message the gif file is uploaded. Content-Type is set both when presigning and also in PUT message, but in AWS interface gif type is not visible. Why?
PUT request header:
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en,nl;q=0.9,hu;q=0.8,de;q=0.7
Cache-Control: no-cache
Connection: keep-alive
Content-Length: 10912652
Content-Type: image/gif. // <---------------
Host: t44-post-cover.s3.eu-central-1.amazonaws.com
Origin: http://localhost:3000
Pragma: no-cache
Referer: http://localhost:3000/
sec-ch-ua: ".Not/A)Brand";v="99", "Google Chrome";v="103", "Chromium";v="103"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "macOS"
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36
x-amz-acl: public-read
If image is uploaded from web interface, gif type is visible.
Content-type is S3 metadata. So to change it, you have to modify the metadata properties of your objects.
I'm using Django Rest Framework and Vue.js to build a basic web app, and am currently working on the auth. Using axios to send a post request while registering a new user returns 401 in Chrome for some reason, but works in other browsers (Edge) and returns a 201 Created.
The error in chrome is "detail: Invalid Token", but this particular endpoint (registration) doesn't even need auth/token to access.
My frontend is at http://192.168.1.33:8080 and my backend is at http://127.0.0.1:8000
I am trying to POST data to http://127.0.0.1:8000/api/v1/users/auths/
The Network tab in chrome dev tools after trying a request:
Request URL: http://127.0.0.1:8000/api/v1/users/auths/
Request Method: POST
Status Code: 401 Unauthorized
Remote Address: 127.0.0.1:8000
Referrer Policy: strict-origin-when-cross-origin
Access-Control-Allow-Origin: http://192.168.1.33:8080
Allow: GET, POST, HEAD, OPTIONS
Content-Length: 27
Content-Type: application/json
Date: Mon, 06 Dec 2021 12:19:15 GMT
Referrer-Policy: same-origin
Server: WSGIServer/0.2 CPython/3.8.5
Vary: Accept, Origin
WWW-Authenticate: Token
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Authorization: Token acf8b9099de5eba413dea141ce2c06b6cfb03159
Connection: keep-alive
Content-Length: 53
Content-Type: application/json
Host: 127.0.0.1:8000
Origin: http://192.168.1.33:8080
Referer: http://192.168.1.33:8080/
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="96", "Google Chrome";v="96"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36
The network tab in Edge dev tools after trying the same thing:
Request URL: http://127.0.0.1:8000/api/v1/users/auths/
Request Method: POST
Status Code: 201 Created
Remote Address: 127.0.0.1:8000
Referrer Policy: strict-origin-when-cross-origin
Access-Control-Allow-Origin: http://192.168.1.33:8080
Allow: GET, POST, HEAD, OPTIONS
Content-Length: 89
Content-Type: application/json
Date: Mon, 06 Dec 2021 12:20:25 GMT
Location: http://127.0.0.1:8000/api/v1/users/auths/12/
Referrer-Policy: same-origin
Server: WSGIServer/0.2 CPython/3.8.5
Vary: Accept, Origin, Cookie
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Authorization
Connection: keep-alive
Content-Length: 51
Content-Type: application/json
Host: 127.0.0.1:8000
Origin: http://192.168.1.33:8080
Referer: http://192.168.1.33:8080/
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="96", "Microsoft Edge";v="96"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.55 Safari/537.36 Edg/96.0.1054.43
The obvious difference is that there is a "WWW-Authenticate: Token" in the Chrome Network tab, which is odd.
CORS headers and all have been set up properly, plus the issue is only in Chrome. Is this some Chrome quirk, or am I missing something?
Why is it that, after spending some two hours on a problem, you only get the answer after you've posted it on a forum? Probably something to do with putting the problem down categorically and formally...
Anyway. Turns out the issue was with there being a random token sitting in Chrome's local storage, which was causing all the trouble with the "invalid" token. I cleared local storage, and it's working now. No clue why I had to do this specifically — I had made sure to clear the cache earlier...
See the following GET request headers. I would like some direction regarding forming these GET requests using libcurl in C++.
GET url.aspx?TabID=100000021 HTTP/1.1
Host: url.net
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: http://url/Login.aspx?BackToStartPage=true
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: erJOJPQYCFBMNUJDDYWOH5; ASP.NET_SessionId=ickaamclvh45; BIGipServer~url~Flexnet-url-Prod.app~url-Prod_pool=rd1o00006a0do80; WebPortalSession=77d0601a4_1; LoginPageCookie=http://url/Login.aspx?CurrentUserLanguageId=1033&CurrentUserTimeZoneId=1129; .ASPXAUTH=92C511D2B670AE9DDC3D55A88BBEF6CAF16FBBF0BFFFB016C20B655BAB1B54428F9C55A8430F806F74211354557A8A918DFD8FE9589BF3F95D0340180E89806C4BDF7813CCD5DC027349F8714B1A319C1E51E8C43
GET url.aspx?TabID=0 HTTP/1.1
Host: url.net
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: http:/url.net/Login.aspx?BackToStartPage=true
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: &LGN=MIYDMMBQGUZTS; ASP.NET_SessionId=ickaax45p; url~url~url-url-Prod.app~url-url-Prod_pool=rd1o0000o80; WebPortalSession=77d0601a9_1; LoginPageCookie=http://url.net/Login.aspx?CurrentUserLanguageId=1033&CurrentUserTimeZoneId=1129; .ASPXAUTH=7516499A62192592C485B17AF1D3BDB25DBDE26DF6A1FC179CC3658F3AD1E74E32
I'm currently running a Python Flask Application on Amazon Elastic Beanstalk. When I test the application, it all works fine locally (I used Postman to send the GET & POST requests). However, on AWS, it doesn't work because the request that gets to my EC2 instances (behind the load balancer) does not include the Authorization header. It seems like the load balancer strips off the header. Is there something I'm doing wrong here?
Here's a comparison of what I get when I print out the header locally and on Elastic Beanstalk.
Locally
[2017-07-04 13:18:14,650] [INFO] [common.decorators] Headers = Host: localhost:5000
Connection: keep-alive
Content-Length: 151
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Cache-Control: no-cache
Origin: chrome-extension://fhbjgbiflinjbdggehcddcbncdddomop
Content-Type: application/json
Authorization: Bearer ad9fd4d9-6ce6-497b-855a-dcebebdad65b
Postman-Token: xxxxx
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8
Elastic Beanstalk:
[2017-07-04 17:27:03,813] [DEBUG] [common.decorators] Headers = Accept-Language: en-US,en;q=0.8
Accept: */*
Host: dev.onetext.com
X-Forwarded-For: 66.30.13.108
Content-Type: application/json
Postman-Token: xxxxx
Connection: keep-alive
Accept-Encoding: gzip, deflate, sdch, br
X-Forwarded-Proto: https
Cache-Control: no-cache
X-Forwarded-Port: 443
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Thanks to the comment added by #notionquest, I found the solution at https://forums.aws.amazon.com/thread.jspa?messageID=729128
I solved this by adding a new file under the .ebextensions folder with the following content:
files:
"/etc/httpd/conf.d/wsgihacks.conf":
mode: "000644"
owner: root
group: root
content: |
WSGIPassAuthorization On
AWS do not accept unserscores (_) in headders, while we can use (-), So Remove underscores from the header variables, example:-
header_var_val = "some value"
replace it with
headervarval = "some value"
It works for me
I am currently using GrapheneDB for my Neo4J database which I am pulling information from my Ember application. Neo4J requires Basic HTTP Authentication and since I want a more secure method (instead of explicityly stating the headers in my ajax calls), I am trying to use a http-proxy to connect to the database. So via Ember-CLI, I generated a http-proxy with a path at '/api'. Within the proxy file, I have the following:
~/server/proxies/api.js
var proxyPath = '/api';
module.exports = function(app) {
// For options, see:
// https://github.com/nodejitsu/node-http-proxy
var proxy = require('http-proxy').createProxyServer({});
var path = require('path');
app.use(proxyPath, function(req, res, next){
var credentials = new Buffer('app-id:app-pw').toString('base64');
// include root path in proxied request
req.url = path.join(proxyPath, req.url);
req.headers.authorization = "Basic " + credentials;
proxy.web(req, res, { target: 'http://app-id.sb02.stations.graphenedb.com:24789/db/data/' });
});
};
So when the above is ran, the headers when printed out on the server seems correct:
{ host: 'localhost:4200',
connection: 'keep-alive',
'cache-control': 'max-age=0',
accept: 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8',
'user-agent': 'Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36',
'accept-encoding': 'gzip,deflate,sdch',
'accept-language': 'en-US,en;q=0.8',
authorization: 'Basic <correct base64 hash>' }
But when going to the my api URL, I get the following request headers:
GET /api HTTP/1.1
Host: localhost:4200
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
And I get a 404 Not Found. But when I remove the authorization header, I get a 401 Unauthorized prompting me for a username/password. Sometimes on the headers it will show: "Authorization: Basic Og==". Either way it doesn't work.
Does anyone know a solution to this? I tried both the example setHeader code in the node-http-proxy documentation and also searched all over the interwebs for information on ember http-proxy but to no avail. Thanks in advanced!
I'm just spit balling here because I can't test this out but I think you have it working. You're getting a 404 because you're requesting 'http://app-id.sb02.stations.graphenedb.com:24789/db/data/api' which probably doesn't exist. It may also be because of the accept header. If you're trying it out in the browser the accept header is text/html but your target may be expecting application/json in which case it 404s. You could try curling it to test this out 'curl -H "ContentType:application/json" [target]'.
As GOULETGOULET stated, '/api' was appended to the end of the target URL and no such directory exists in my target. So swapping it to 'db/data' worked.