Response to TRACE http method - trace

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).

Related

Postman and content-length

From my laptop I initiated a POST request to my web server. The HTTP POST request looks something like this (when seen via POSTMAN console)
POST /api/fwupgrade HTTP/1.1
User-Agent: PostmanRuntime/7.24.1
Accept: */*
Cache-Control: no-cache
Postman-Token: 2b1e72fa-f43b-4fc9-9058-e78533c30f0f
Host: 192.168.71.24
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Type: multipart/form-data; boundary=--------------------------572971355726244237076370
Content-Length: 222
----------------------------572971355726244237076370
Content-Disposition: form-data; name="FileName"; filename="help.txt"
<help.txt>
The content-length is indicated as 222. the file help.txt has the following characters only (for test I put 10 a)
aaaaaaaaaa
When I receive a http request on the server, I parse the request and I see the content-length as 222. Now my questions:
a) I assume this content length 222 includes the bytes after the line "Content-Length: 222" am I right? So this would mean the request body starts from
------------------572971355726244237076370
Content-Disposition: form-data; name="FileName"; filename="help.txt"
<help.txt>
Is this understanding correct?
b) Does the request body always follow the same format i.e after "Content-Length:" it begins and ends with the data of the file, in my case "help.txt"?
c) Assuming #a is correct, I calculate the actual data to be starting from the location after filename="help.txt" /r/n and then store this in a file on my server. However I get 58 surplus bytes after the aaaaaaaaaa. Any idea how am I supposed to interpret Content-length or how postman calculates the Content-length field?
Regards
a) Roughly yes.
b) It depends on the Content-Type (here: multipart/form-data)
c) You'll need a parser for multipart/form-data messages. See, for instance, https://greenbytes.de/tech/webdav/rfc7578.html

Generate Sequential POST requests via fiddler

I am quite new to Fiddler and it looks like an awesome tool to me.
What i wanted to do is generate a sequence of POST requests.
Explaination:
POST https://www.website.com/user/login HTTP/1.1
Host: www.website.com
Connection: keep-alive
Content-Length: 552
Cache-Control: max-age=0
Origin: https://www.website.com
Upgrade-Insecure-Requests: 1
DNT: 1
Content-Type: application/x-www-form-urlencoded
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8
Referer: https://www.website.com/user/login
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cookie: ASP.NET_SessionId=mpdxdkrjujkzchwblg1ys2y3; ai_user=u0IpN|2018-09-25T16:12:07.607Z; ai_session=+Ip5T|1537899054881.5|1537899121420.5
__VIEWSTATE=something here PageContent%24txtRoll=14600&ctl00%24PageContent%24txtDOB=01%2F01%2F2001&ctl00%24PageContent%24btn_submit=LOGIN
i want to make a loop of request such that the DOB field takes value like
01%2F01%2F2001
then, 01%2F02%2F2001
then, 01%2F03%2F2001
and so on.. keeping everything else same.
And if the response from server is Code:302 then stop the loop or otherwise if the value reaches 31 then too stop the loop.
Thanks in advance.
Any suggestions are welcome.
P.S. :Sorry for the messy question, i don't know how could i say it in simple words.
You need to write a script which will do that for you. Here's an article that might help you.
https://www.telerik.com/blogs/understanding-fiddlerscript
Personally I'd write a script that does the task in python or any other language you know using any http library

Embe Data: How to update a record

I've got an record of my model 'item' via
store.find('item', 412).then(function(item){
...
});
The model looks like that:
item :{
title: "mySuperItem",
price: "45",
comments: [
23423,
656332
]
}
However, what I want is to change the comments IDs in the founded record (want to add a new one).
So I thought it would be fine to do something like that:
...
.then(function(item){
item.comments.push(234234);
item.save().then(...);
});
Unfortunately it's not working as expected. Ember throws curious exceptions!
Since I'm writing my Backend with the REST-API on my own (nodes.js/express.js) ember-data will send a simple OPTIONS-Call to the backend with the following headers:
Host: localhost:3000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:42.0) Gecko/20100101 Firefox/42.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Origin: http://localhost:4200
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: content-type,x-access-token
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
My backend will return a answer which contains that header: Allow:"GET,HEAD,PUT" so it seems like my backend answered "Hey its okay to send PUT-Calls to that address". But ember prompts me to use CORS, but its not working since the method cannot be found in the CORS-Header 'Access-Control-Allow-Methods'.
How could that be? Maybe I misunderstand something
Edit for addition
As #torazaburo mentioned correctly, the model for Item has of course a hasMany-relation to "comments"-model. However here is the model for Item:
title: DS.attr('String'),
price: DS.attr('Number'),
comments: DS.hasMany('comment')
Also its now more clear that the problem is with the save()-Part. Its throws an unexpected "cross-origin" error as described above.
Any Help?
I think you should set Access-Control-Allow-Origin header also. For example:
Access-Control-Allow-Origin: *

Missing detail in answer to HTTP-OPTION

I'm trying to find out the problem in a communication issue between my klient and a REST API.
I can identify the problem but I'm not sure what is exactly missing in the answer for the OPTION request.
My application is creating a HTTP POST what is preflighted by the browser with a HTTP-OPTION. The option is asking for approving the custom Content-type. After the server answers the OPTION the POST is not sent.
OPTIONS /element_collection/VizRundown/channels/ExampleChannel/playlists/continuous/ HTTP/1.1
Host: localhost:8580
User-Agent: Mozilla/5.0.........
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type
Accept: */*
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US......
Origin: null
Here is how the answer looks like:
200 OK
Access-Control-Allow-Origin: *
Allow: GET, POST, OPTIONS
Content-Type: text/plain
Server: MediaSequencer/1.23.1.11957 soul/014dfd135460
Transfer-Encoding: chunked
Am I correct that there should be a line int the answer approving the requested Content-Type? Like this:
Access-Control-Allow-Headers: content-type
No, it is not required as per the relevant sections of the spec.
http://www.w3.org/TR/cors/#resource-preflight-requests:
In response to a preflight request the resource indicates which
methods and headers (other than simple methods and simple headers) it
is willing to handle and whether it supports credentials.
http://www.w3.org/TR/cors/#terminology:
A header is said to be a simple header if the header field name is an
ASCII case-insensitive match for Accept, Accept-Language, or
Content-Language or if it is an ASCII case-insensitive match for
Content-Type and the header field value media type (excluding
parameters) is an ASCII case-insensitive match for
application/x-www-form-urlencoded, multipart/form-data, or text/plain.

How to Determine encoding/compression of the string which appears like characters are dancing in gangam style

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==