I have this HTTP response content :
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Transfer-Encoding: chunked
Date: Mon, 12 Aug 2013 15:08:10 GMT
PK�Ctemps_attente.json���n� �߅9�Bw���VU��Uߠs���^��#�CGç��ͷ�r7G�3Hnp����^pYSu\#Qo%~x��FGa�Y�ا����S���-ua���t��j-���s�%э��+,g�xq.��������t�fb� �0:)�:�K�}^�N�L����>�щ%#�̲x`C#��m݃ :^��$~�i8���WzCh�a�ă���7t�O|��AX˂��UO$���<��y"�;�'F��]��{֘Ha}F��<��l6��o벰V���66t�&��f�Ť��x�H��툗���/PKA�Y�1�PK�CA�Y�1�temps_attente.jsonPK#q
I would like to know what format is the response and how to decompile to have the final response.
I tried to use this function: http_chunked_decode but I did not succeed.
The body (or at least what appears to be the body) of the response is not chunked.
It does appear to be compressed - with HTTP this should be expressly stated in the headers,
There is no blank line between the what appears to be the headers and what appears to be the body.
If this is really the response you are getting it's not HTTP - an off-the-shelf function is not going to make sense of it.
Related
What are this Weird Characters on my Ajax result 138d on the start and 0 on the end of my ajax result. how to disable this?
138d
{"feeds":[{"pubdate":"Sun, 28 Nov 2021 23:00:00 EST"]}
0
Your HTTP client is buggy. It improperly extracted the body from the HTTP response.
There are three ways to signaling the end of an HTTP response:
Using a Content-Length header.
Using the chunked transfer coding.
Closing the socket.
The first two methods allow more than one request-response exchange to occur over the same connection, which is far more efficient than creating a new connection for each request. (Especially for HTTPS.)
The Content-Length header is quite simple to use, but it requires knowing the size of the message body before starting to send it. The chunked transfer coding doesn't have that limitation. It allows servers to start sending a response before its size becomes known.
An HTTP response that uses the chunked transfer coding might look like this:
HTTP/1.1 200 OK␍␊
Transfer-Encoding: chunked␍␊
Content-Type: application/json␍␊
␍␊
28␍␊
..............................␍␊
28␍␊
..............................␊␍␊
0␍␊
The message body of that response is
............................................................␊
The response that returned your JSON apparently used the chunked transfer coding. And whatever you used to parse the HTTP response incorrectly returned the still-chunked message body. This is a bug. Quote RFC2616,
All HTTP/1.1 applications MUST be able to receive and decode the
"chunked" transfer-coding
Getting response from one of the soap function php, after that sending this response as a parameter to another soap request, that time I need to extract the set-cookie from the previous response header here below my response header. I need to read set-cookie JSESSIONID element ?
HTTP/1.1 200 OK
Set-Cookie: **JSESSIONID=9A977E193F9B505B084D95C3028BAD0C.srv1816**;
Path=/webservices
Content-Type: text/xml;charset=UTF-8
Transfer-Encoding: chunked
Date: Mon, 15 Apr 2019 07:38:52 GMT
Set-Cookie: aeroID=12988141315553139361555313936504655;Path=/;
Expires=Sun, 09-Feb-2020 07:38:56 GMT
You could just read your JSESSIONID cookie like so :
First get your cookies :
import com.eviware.soapui.impl.wsdl.support.http.HttpClientSupport
def cookieStore= HttpClientSupport.getHttpClient().getCookieStore()
Then just find the one that interest you
def cookies = cookieStore.getCookies()
def jsessionidCookie
cookies.each {
if(it.name == "JSESSIONID")
jsessionidCookie= it
}
I did R&D on prevention of CRLF injection in php, but i didn't find any solution in mycase, as I'm using a burp suite tool to inject some headers using CRLF characters like the below.
// Using my tool i put CRLF characters at the start of my request url
GET /%0d%0a%20HackedHeader:By_Hacker controller/action
//This generates an header for me like below
HackedHeader:By_Hacker
So i can modify all headers by doing just like above
This tool is just like a proxy server so it catches the request and gives the response and we can modify the response in the way we want.
So i'm just modifying the response by injecting some headers using CRLF characters. Now the Server responds to this request by injecting the CRLF characters in the response.
I'm just worried as header fields like Pragma, Cache-Control, Last-Modified can lead to cache poisoning attacks.
header and setcookie contain mitigations against response/header splitting, But these can't support me in fixing the above issue
Edit
When i request to mysite.com contact us page like below This is the request I captured in my tool like below
Request headers:
GET /contactus HTTP/1.1
Host: mysite.com
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
And i get the Response HTML for the above request
Now for the same request using the tool i'm adding custom headers just like below
Request Headers:
GET /%0d%0a%20Hacked_header:By_Hacker/contactus HTTP/1.1
Host: mysite.com
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Response Headers:
HTTP/1.1 302 Found
Date: Fri, 10 Jul 2015 11:51:22 GMT
Server: Apache/2.2.22 (Ubuntu)
Last-Modified: Fri, 10 Jul 2015 11:51:22 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Location: mysite.com
Hacked_header:By_Hacker/..
Vary: Accept-Encoding
Content-Length: 2
Keep-Alive: timeout=5, max=120
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
You can see the injected header Hacked_header:By_Hacker/.. in the above response
Is there anyway in php or apache server configuration to prevent such kind of headers' hack?
Not sure why all the down votes - infact, it is an interesting question :)
I can see that you have tagged CakePHP - which means your app is using Cake Framework... Excellent! If you are using Cake 3 , it is automatically strip off : %0d%0a
Alternatively, where you receive the response header, just strip off %0d%0a and you are good!
Where things like these could be applied - a 3rd party API response or say.... a Webhook response! or a badly sanitized way to handle intl.. example : lang=en to lang=fr where the GET param is directly set as response header... That would not be a wise move!
Ideally, the responses will be as GET and not in the header but either way just strip the %0d%0a and you are good.
Answering your edit.
You can see the injected header Hacked_header:By_Hacker/.. in the above response
That injected header cannot be controlled or stopped, mate. We do not have control over what the other server does.
The question is.. What do you do with the response header?
The answer is... You sanitize it, as ndm said you need to sanitize the input.. What you get as a response IS an input. As soon as you detect %0d%0a, discard the response.
Need code work?
<?php
$cr = '/\%0d/';
$lf = '/\%0a/';
$response = // whatever your response is generated in;
$cr_check = preg_match($cr , $response);
$lf_check = preg_match($lf , $response);
if (($cr_check > 0) || ($lf_check > 0)){
throw new \Exception('CRLF detected');
}
I am doing some API requests using fsockopen() in PHP. For most APIs that works correctly, but from http://geocoding.cloudmade.com/ I get the following (RAW) response:
HTTP/1.1 200 OK
Server: nginx/0.6.35
cache-control: no-cache
Content-Type: application/json; charset=utf-8
Date: Tue, 19 Feb 2013 11:08:05 GMT
pragma: no-cache
Transfer-Encoding: chunked
Connection: close
2fb
{"found": 1, "bounds": [[52.48732, 13.42553], ...
0
My problem is that "2fb" in the first line and the "0" in the last line of the body does not tell my anything. If I send the same request via Firefox, the body does not contain a "2fb" or "0". Therefore, I guess it has some meaning. But what?
Thanks for hints!
That is chunked transfer-coding, also indicated by the Transfer-Encoding: chunked response header:
The chunked encoding modifies the body of a message in order to
transfer it as a series of chunks, each with its own size indicator,
followed by an OPTIONAL trailer containing entity-header fields. This
allows dynamically produced content to be transferred along with the
information necessary for the recipient to verify that it has
received the full message.
2fb, followed by \r\n, indicates the size of the following chunk (763 bytes). A chunk-size of 0 indicates the last chunk.
I have been using WebDAV in PHP directly using XML. I have managed to create emails with attachments and so forth, but when i try to create a contact, I keep getting "400 Bad Request". Here is the webdav query and how i'm executing it:
<?xml version="1.0"?>
<g:propertyupdate
xmlns:g="DAV:"
xmlns:c="urn:schemas:contacts:"
xmlns:e="http://schemas.microsoft.com/exchange/"
xmlns:mapi="http://schemas.microsoft.com/mapi/"
xmlns:x="xml:"
xmlns:cal="urn:schemas:calendar:"
xmlns:mail="urn:schemas:httpmail:">
<g:set>
<g:prop>
<g:contentclass>urn:content-classes:person</g:contentclass>
<e:outlookmessageclass>IPM.Contact</e:outlookmessageclass>
<c:givenName>JoLynn</c:givenName>
<c:middlename>Julie</c:middlename>
</g:prop>
</g:set>
</g:propertyupdate>
And response:
HTTP/1.1 400 Bad Request
Connection: close
Date: Mon, 05 Jul 2010 08:41:43 GMT
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Content-Type: text/html
Content-Length: 1709
MS-WebStorage: 6.5.7638
And sending the data: $h->fetch($url, 0, null, $exchange_username, $exchange_password, "PROPPATCH")
Any help greatly appreciated!¬
I started with Troy Wolf's example code at http://www.troywolf.com/articles/php/exchange_webdav_examples.php
Ah i fixed it, forgot to send some headers with the request (content-type, depth and translate headers to be precise!)