So I was testing my website and I tried connecting with the TRACE http method. In response I got a massive string. I don't know what it is. Does anybody know what could it be and if it's some sort of vulnerability?
This is the string I'm talking about:
VFJBQ0UgLy5odHBhc3N3ZCBIVFRQLzEuMQ0KSG9zdDogd3d3LnNzZmt6LnNpDQpVc2VyLUFnZW50OiBNb3ppbGxhLzUuMCAoWDExOyBMaW51eCB4ODZfNjQ7IHJ2OjkxLjApIEdlY2tvLzIwMTAwMTAxIEZpcmVmb3gvOTEuMA0KQWNjZXB0OiB0ZXh0L2h0bWwsYXBwbGljYXRpb24veGh0bWwreG1sLGFwcGxpY2F0aW9uL3htbDtxPTAuOSxpbWFnZS93ZWJwLCovKjtxPTAuOA0KQWNjZXB0LUxhbmd1YWdlOiBlbi1VUyxlbjtxPTAuNQ0KQWNjZXB0LUVuY29kaW5nOiBnemlwLCBkZWZsYXRlDQpDb25uZWN0aW9uOiBrZWVwLWFsaXZlDQpDb29raWU6IGpzQ29va2llV2FybmluZ0NoZWNrPWRlY2xpbmVkDQpVcGdyYWRlLUluc2VjdXJlLVJlcXVlc3RzOiAxDQpDYWNoZS1Db250cm9sOiBtYXgtYWdlPTAsIG5vLWNhY2hlDQpPcmlnaW46IGh0dHA6Ly93d3cuc3Nma3ouc2kNClByYWdtYTogbm8tY2FjaGUNCg0K
It's a Base64 encoded string. Decoded it looks like this:
TRACE /.htpasswd HTTP/1.1
Host: www.ssfkz.si
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cookie: jsCookieWarningCheck=declined
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0, no-cache
Origin: http://www.ssfkz.si
Pragma: no-cache
Which per se does not really look like a security flaw and much rather like a basic implementation of the TRACE http method which states that the contents of the request shall be reflected in their entirety in the response body.
Interesting note though, looking at the specification:
A client MUST NOT generate header fields in a TRACE request containing sensitive data that might be disclosed by the response. For example, it would be foolish for a user agent to send stored user credentials [RFC7235] or cookies [RFC6265] in a TRACE request. The final recipient of the request SHOULD exclude any request header fields that are likely to contain sensitive data when that recipient generates the response body.
So ideally the response should not have contained the Cookie header (to fully comply with the specification by my understanding the client you used to send the requests should not have included them in the first place however).
I'm trying to issue a GET command to my local server using netcat by doing the following:
echo -e "GET / HTTP/1.1\nHost: localhost" | nc localhost 80
Unfortunately, I get a HTTP/1.1 400 Bad Request response for this. What, at the very minimum, is required for a HTTP request?
if the request is: "GET / HTTP/1.0\r\n\r\n" then the response contains header as well as body, and the connection closes after the response.
if the request is:"GET / HTTP/1.1\r\nHost: host:port\r\nConnection: close\r\n\r\n"
then the response contains header as well as body, and the connection closes after the response.
if the request is:"GET / HTTP/1.1\r\nHost: host:port\r\n\r\n" then the response contains header as well as body, and the connection will not close even after the response.
if your request is: "GET /\r\n\r\n" then the response contains no header and only body, and the connection closes after the response.
if your request is: "HEAD / HTTP/1.0\r\n\r\n" then the response contains only header and no body, and the connection closes after the response.
if the request is: "HEAD / HTTP/1.1\r\nHost: host:port\r\nConnection: close\r\n\r\n" then the response contains only header and no body, and the connection closes after the response.
if the request is: "HEAD / HTTP/1.1\r\nHost: host:port\r\n\r\n" then the response contains only header and no body, and the connection will not close after the response.
It must use CRLF line endings, and it must end in \r\n\r\n, i.e. a blank line. This is what I use:
printf 'GET / HTTP/1.1\r\nHost: www.example.com\r\nConnection: close\r\n\r\n' |
nc www.example.com 80
Additionally, I prefer printf over echo, and I add an extra header to have the server close the connection, but those aren’t needed.
See Wiki: HTTP Client Request (Example).
Note the following:
A client request (consisting in this case of the request line and only one header) is followed by a blank line, so that the request ends with a double newline, each in the form of a carriage return followed by a line feed. The "Host" header distinguishes between various DNS names sharing a single IP address, allowing name-based virtual hosting. While optional in HTTP/1.0, it is mandatory in HTTP/1.1.
The absolute minimum (if removing the Host is allowed ;-) is then GET / HTTP/1.0\r\n\r\n.
Happy coding
I was able to get a response from my Apache server with only the requested document, no response header, with just
GET /\r\n
If you want response headers, including the status code, you need one of the other answers here though.
The fact of the 400 Bad Request error itself does not imply that your request violates HTTP. The server very well could be giving this response for another reason.
As far as I know the absolute minimum valid HTTP request is:
GET / HTTP/1.0\r\n\r\n
Please, please, please, do not implement your own HTTP client without first reading the relevant specs. Please read and make sure that you've fully understood at least RFC 2616. (And if you're ambitious, RFC 7230 through 7235).
While HTTP looks like an easy protocol, there are actually a number of subtle points about it. Anyone who has written an HTTP server will tell you about the workarounds he had to implement in order to deal with incorrect but widely deployed clients. Unless you're into reading specifications, please use a well-established client library; Curl is a good choice, but I'm sure there are others.
If you're going to implement your own:
do not use HTTP/0.9;
HTTP/1.0 requires the query line and the empty line;
in HTTP/1.1, the Host: header is compulsory in addition to the above.
Omitting the Host: header in HTTP/1.1 is the most common cause of 400 errors.
You should add an empty line: \r\n\r\n
http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Client_request
The really REALLY BARE minimum, is not using netcat, but using bash itself:
user#localhost:~$ exec 3<>/dev/tcp/127.0.0.1/80
user#localhost:~$ echo -e "GET / HTTP/1.1\n" >&3
user#localhost:~$ cat <&3
HTTP/1.0 200 OK
Server: SimpleHTTP/0.6 Python/2.7.6
Date: Mon, 13 Oct 2014 17:55:55 GMT
Content-type: text/html; charset=UTF-8
Content-Length: 514
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"><html>
<title>Directory listing for /</title>
<body>
<h2>Directory listing for /</h2>
<hr>
<ul>
</ul>
<hr>
</body>
</html>
user#localhost:~$
I'm trying to make a 'DEL' REST request using Soapui Pro. One of the parameters includes a value containing '+' (which gets treated as SPACE if not UTF-8 encoded). Soapui doesn't seem to URL encode the request even though tried to re-enforce encoding in the REST request step.
Secondly, i tried to pass UTF-8 encoded value (encoded by a groovy step). But Soapui seems to, some how, automatically. decode the value before sending. Am i missing something here? Please help.
Sample request (RAW)
Sensitive data masked by XXXXX, YYYYY
DELETE https://XXXXXservices.com/XXXXX_services/ogw/emf/securityShare/888247189312/members?shareId=8882015810875&memberIds=XXXXX&auth-username=YYYYY&auth-nonce=XIX9UL9UBIE2L8K&auth-sharedkeyid=System&auth-expiresby=1414607713258&auth-algorithm=HMACSHA256&auth-signature=9JmAxG6rkqZe0Fu+zPQIh9Eh3tazDoE1YBZFxgIRLMc= HTTP/1.1
Accept-Encoding: gzip,deflate
Host: XXXXXservices.com
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
While analyzing the HTTP Requests OF a website. I found that in one of the POST request it sends three postdata to the server the first one was SAML data first base64 encoded then urlencoded.
But I am not able to figure out the value of other two postvars. One thing I am sure about is that it is not using any encryption methods like md5 or sha1 etc. COZ the response text contains my user name value which according to my research is neither stored in session variable or cookies means this encoding of post data can be reversed. So I am guessing that may be my user name "RAHUL" is inside one of these post variables. But am unable to read it.
First String:
sRrWj1zUsisp/UylJiEf/pekY//ok1nYAAcvJfkxL9kMEggMAX0jTTs1hPPKTU9d1u/qgdq6eIvS
nk3NT6KkR9bKiGyQKY5iJ39JXGNlBvxs3F9N7TMHUBeNZ2BSDg05dTyYtdiVffRDnQ5KgDCy7ZjG
Lzj5J3x3LJumTau7aFc5CZ2b4xqzEPc4kGVcg/6l5D7Hxonp6U/0DnIzemcrXfb95X40CidNmz1J
PlGaeZzgAsA619vhs3AlGPNZ/Nbbm7IsJlVcKY6TvigrP0jMCp/0BvYb45gztvaJicN43JrNUsgc
+CLKaTvxflkLhul/sAe5Gbm83AtR/kNKQZf2hg==
Second String:
Og5+F9RTHNs7NqUEYpgGSshInxZQzCP3gU2fkI8VnS60Ce2hmurlTLn6IcdP63zUkrDbdA2/+J00
DNgD15yW2lNo5Zi3PdfEEOxFjw8L5/RFwoIrMzTzS8csZaWqSAfqW1GiE4hbpAgeKZ4pXrmTLy2A
/AfT90uCptaoEa19qzD6/5o2+G4lCeJf5ZUMeZRMLvX3U909TlzCggf9KsHeJpfXGnGEefu9o0V9
kbQ5FzLEuao9ByCnXaFBEcDBDAFljrK0fsqJyLyv2gnhj4IOcCAEowa9N6tBsu/ngac9uR+NHY4+
r4l67i+nt5CRZ9PRLq/hT2qCoy6PguhDOEHbgg==
When I decoded the above strings using base64 decoder it returns unreadable value. I want to know what to do next so as to get useful data inside it.
I am pasting the complete post request including Headers and form data.
HEADERS
Host: xxxx.xxxx.xxxx.xxxxxxx
User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:20.0) Gecko/20100101 Firefox/20.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:xxx.xxx.com/xxxxxx/adsf
Cookie: _abc_abc_session=1032510200e6bf9a8ae265553120e1ca;
AWSELB=F7610D8306188BFF856DC4E8C0134950D9FBEC546F2ACFBA970F103CC9E2B9074253115B0BB906564BB68191596A2637A0D1F52106813C785600B014A199891F5B8C6C8420
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 8725
FORM
TARGET: www.XXVVVVVVVVVF.com/sessions/consume
SAMLResponse: XXXXXXXXXX
APID: ap_00001
pca_red74:
KiiYkBzqSHEKWu2Q//CgZg47iEBSOkU1Ew3yaUIAQNqHAf8AwZVLQXdNw5ZF0B67WJH46JDKQ/sP
Cypp2sofHA/Eq0gXMoH7yZt3RG0LXTuNANYNr/chOx4kks0/fINjpowPXTiSkWc0bsXimWH62BZy
mq7TATEsXM6w4ywu1cVTP+/DlfNy3Mf0V3VVwEjMWwtR/3X8zKgtRJKMTtwe/YGhus6YefSEknPO
pO9oy3zdDy0Yp7qRp93tPAdxRSXyIsJs5bJlefH8o5QSzsk7hlBhQFhd/OlKpMCsYMDSOHa+FJ1K
AqEWgH0eMzczO6LFhVdhAAm3DFaAvxL4u+DkuQ==
pca_red75:
tU48SalKFzVys9fZR1Se+5xP1dlOh9SlbYBT/Ct6BGiyIFEVEdyq2XR7BDuz/0BAsMfGwhgwI3Ws
uNk6KnEyOBIX+9u0eFer/VoHkGydw8310fGxJiiq13BYHnkzk9OLZCdD43VF27a6SvEtaA/LXnm4
ZrURgpoFWtfBmaC4zIkHkYgXW5wTYeJ1Ze0rgmBYPFlms2BefeRricA68NR3OsbSoCmwIKfuWe+2
esM4RN8t9jG/nccM2EeluDXRKJHA09O02Lq7KBhZw5o2OBCQ7nDc9p47Poli0as1yo+ylHfjJOag
qCeVuPBCLEwpJL74CreuzJGAYqSOVA9BOx5SQA==
I building a module for compressing HTTP output. Reading the spec, I haven't found a clear distinction on a couple of things:
Accept-Encoding:
Should this be treated the same as a Accept-Encoding: * or as if no header is present?
Or what if I don't support gzip, but I get a header like this:
Accept-Encoding: gzip
Should I return a 406 error or just return the data unencoded?
EDIT:
I've read over the spec a few times. It mentions my first case, but it doesn't define what the behavior of the server should be.
Should I treat this case as if the header is not present? Or should I return a 406 error because there's no way to encode something given the field value ('' isn't a valid encoding).
There is written everything in the Spec: 14.3 Accept-Encoding:
The special "*" symbol in an Accept-Encoding field matches any
available content-coding not explicitly listed in the header
field.
If an Accept-Encoding field is present in a request, and if the server cannot send a response which is acceptable according to the Accept-Encoding header, then the server SHOULD send an error response with the 406 (Not Acceptable) status code.
edit:
If the Accept-Encoding field-value is empty, then only the "identity"
encoding is acceptable.
In this case, if "identity" is one of the available content-codings, then the server SHOULD use the "identity" content-coding, unless it has additional information that a different content-coding is meaningful to the client.
What is "identity"
identity
The default (identity) encoding; the use of no transformation whatsoever. This content-coding is used only in the Accept- Encoding header, and SHOULD NOT be used in the Content-Encoding header.