So, I took up the initiative with a collaborative partner (see: https://pwntoken.wordpress.com/2014/02/28/deeper-to-http-perhaps/) to hook up together and do some research on HTTP in order to exploit different web applications as stated on my previous posts/post. This will be a recent update to what I had been working out for days, and in a simpler similar fashion will draft out what is to be expected off the research and what’s so deep about this from a web application security perspective? All the questions will be answered, if not; ask via comments or mail me at email@example.com
To be point closer and to be really very clear, I see a lot of people getting into bug hunting and claiming they knew that they ‘KNOW’ to be furthermore sarcastic and even more humor that the companies and the developers take it as a serious consideration without any checks. Well, that been said; we all know these companies and corporations which are based on web, need real quick fixes, hence why they welcome the ‘skid’ group and let them in to find. Some do use ‘production servers and that’s the latest whine I had to rant upon; but not on this post, maybe sometime later. Onto the specifics, this research and the underlying every draft that is being worked upon is to eliminate this misleading security (web application!) beneath the rack pile of ‘fake-sec-essence’ where it should had belong’d originally.
I insisted to occupy the whole aspect in relation to the HTTP protocol since from the start from HTTP/1.0 until the latest HTTP/2.0 covering HTTP/1.1 at the middle, and sooner realized this was to be for HTTP protocol keeping the security centric aspects. Why?, simpler; because it’s in itself a vast topic. HTTP with the RFC’s if you take a look at IETF is a major draft out there which keeps changing and the older compilation ceases to function! (year:2014). SO, I broadly classified the HTTP documents under private research to be security centric at the taken up protocol and drew out as many conclusions as I could. The document itself is at a beta stage and nothing has been public yet, nor would be as it is supposed to be private. I wanted to make some preview snaps of the copy tho which I shall end up doing so in this post.
The more deep I went, the more I realize it was getting messy and to keep this simpler than the RFC themselves for the web application security aspirants; I broke the document into parts where I had to mention the specific security headers (HTTP Headers!) a their convenient places when mentioned in the document. I chalked out a rough draft for this and named it as ‘a rough draft’ on hardcopy.
The need to convert these security aspects in a convenient way for a soft-copy was a major operation. I hope the partner I collaborated with for this research would keep up his own pace on this major web application exploitation in a neat format. Rest, would be really merged or exchanged as an information flow between us for further studies. I personally kept the document much more security centric as it should had been in the first place as IETF has there own versions of RFC’s which could be easily accessed via the web. What’s the difference are the following considerations!
- Made the document easy to navigate and read with appendixes and prolly I would merge a “Table of Contents” as well. Leave me feedbacks.
- Made the document security centric adding HTTP/2.0 as entirely an additional topic.
- Made the document more readable and adding references because references are an additional help to the readers.
- Kept the document under self update on topics. Added text layouts and additional application level protocols for future research purposes.
- The ‘access control’ and ‘authentication’ mechanisms is being drafted in a more resilient and in a focused manner.
- Session management is now added for ‘real’ bug hunters who do not stop at finding an XSS.
- HTTP beyond the basics is now added,, which adds several other topics, HTTP client hints, Encoding parameters for basic-auth, HTTP signatures, etc…
- Added two more authentication unconvincing and non standard schemes such as ‘Origin Bound Authentication’ and ‘Mutual Authentication Protocol’.
- Added Oauth 2.0 MAC – Message Authentication Code keeping in mind OpenID and other application level protocols which are coming out.
I’ll like to have feedbacks and comments because that would push this to a primarily new level of inspection. I would add other security centric additions to other application level protocols as well and keep updating the repository. I had started this under from the very basics up till the advanced, so if one could ‘actually’ take effort reading it; they would need no other books. I think I will be doing videos too on these after finishing up the older drafts and keep this for informational purposes only.
The preview copies are as follows:
Collectively find: http://postimg.org/gallery/32hxr0ua/6e487d90/
PM me if the links get dead at any point (Drop notifications via firstname.lastname@example.org)
While conducting and maintaining these documents, proper measures were taken as not to malform any request which could produce alternative responses by the webserver. Including the requests sent to google and facebook servers were for educational purposes and were done by using cURL. All requests were properly drafted in the document itself and the responses were shown in clear text or in the snaps. I had noticed already the XSS bug bounty hackers to make a quite a noise without knowing what they were doing at the first place, and when ping’d came up with entirely their new format of stories and ended up gifting me a laugh to my face! Roger out!/-