0

I'm playing a bit with HTTP requests with fiddler. Basically the site is my router interface which asks for a password. The password is then encrypted (with a function i have, branded MD5 of some kind) and passed to the server in the body of the POST request.

Here what i've done:

  1. With fiddler i sniffed the browser GET request (got a redirection 302)
  2. With fiddler i sniffed the server response
  3. With fiddler i sniffed the browser POST request (after typing the password)
  4. Browser successfully logged in.

then:

  1. With fiddler composer i performed a GET request equal to the one sniffed. (got a redirection 302)
  2. With fiddler i sniffed the server response (each time the site provides to the client a different Set-Cookie value which is used in the brand MD5 function for antiXRSF attacks).
  3. With fiddler composer i reproduced the sniffed POST request with a different body content due to the new Set-Cookie value.

The body of the post request is indeed correct because it is calculated by the very same function used by the browser.

What came to my mind now:

  1. I'm using the wrong Set-Cookie value --> not possible since if i try to guess the body content of a browser request with the available parameters, the guess turns out to be correct.
  2. The redirection performed by fiddler is done without the Set-Cookie or with a different one --> i saw i can decide not to follow a redirect, is there a way to decide what to pass in the header during a redirection? I'll test more directly on the redirected url.

Regards,

user217354
  • 145
  • 1
  • 14
  • Have you "sniffed" more than one successful request and compared them? The router may be sending a different (hidden) value with every login page and expecting that value to be returned. – AdrianHHH Aug 31 '16 at 14:03
  • 10/10 were perfect. Code is in clear, you can't mistake. Could it be due to CF or LF ? I mean, when i use the RAW tab of fiddler is it showing the exact data or is it encoding things like Linefeed and carrier return?? I manually encode symbols like +,/,= in the body but perhaps new lines are not automatically? – user217354 Aug 31 '16 at 14:21
  • @AdrianHHH forgot to mention you – user217354 Aug 31 '16 at 14:38
  • Mhhmm now i understand what it is that antiCSRF.js script. Could it be a prevention/protection of some kind? I need to dig in more though – user217354 Aug 31 '16 at 15:25
  • Have you "sniffed" more than one successful request and compared them? Are they identical? Raw means raw. Fiddler shows what is in the request or response. Any encoding is done elsewhere. From the questions in your comments it appears that you do not know whether the successful request and your generated requests are identical. How does the Fiddler recording of your generated requests compare to the recording of successful requests? – AdrianHHH Sep 02 '16 at 08:22
  • Isn't this clear? "By using the "Composer" tab i sent the raw request header+body which is 1:1 to the one that the browser would send." let me edit to "By using the "Composer" tab i sent a raw request header+body which is 1:1 to the raw request that fiddler sees when the browser makes the request." – user217354 Sep 02 '16 at 09:04
  • No it is not clear. You have not answered my very first question, so I repeated it. Your descriptions of what you have done and what you have tried are not at all clear. Please [edit] your question to put in full details of what you have done, what you tried, and what happened in each variation. – AdrianHHH Sep 02 '16 at 10:16
  • @AdrianHHH hopefully it is clearer. – user217354 Sep 02 '16 at 11:25

1 Answers1

0

The redirection performed by fiddler is done without the Set-Cookie

Correct. Fiddler's Composer does not have a cookie jar. If a call returns a cookie via Set-Cookie on a redirect, that cookie is not added to a Cookie header when the redirected request is sent.

EricLaw
  • 56,563
  • 7
  • 151
  • 196