Deeper to HTTP, perhaps?

So, I took up the initiative with a collaborative partner (see: 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

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.

Rough Draft 1 for HTTP protocol.

Rough Draft 1 for security centric HTTP protocol. A closer hardcopy draft.


Rough Draft 2 for HTTP Protocol.

Rough Draft 3

Rough Draft 3 for the HTTP protocol. (Security Centric), illustrating other application level protocols.

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!

  1. Made the document easy to navigate and read with appendixes and prolly I would merge a “Table of Contents” as well. Leave me feedbacks.
  2. Made the document security centric adding HTTP/2.0 as entirely an additional topic.
  3. Made the document more readable and adding references because references are an additional help to the readers.
  4. Kept the document under self update on topics. Added text layouts and additional application level protocols for future research purposes.
  5. The ‘access control’ and ‘authentication’ mechanisms is being drafted in a more resilient and in a focused manner.
  6. Session management is now added for ‘real’ bug hunters who do not stop at finding an XSS.
  7. HTTP beyond the basics is now added,, which adds several other topics, HTTP client hints, Encoding parameters for basic-auth, HTTP signatures, etc…
  8. Added two more authentication unconvincing and non standard schemes such as ‘Origin Bound Authentication’ and ‘Mutual Authentication Protocol’.
  9. 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:
PM me if the links get dead at any point (Drop notifications via









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!/-

Proposed Research topics on HTTP for Penetration Testing on Web Applications.

Not so far away from the sentinel of profound webmasks of the web application era, me along with my recently adopted partner comes to conclusion that we should hit web application a serious try. So here’s it with no longer waits. We had measured the perfect ways for us to consider taking web application penetration testing seriously and this would be the first official post onto the journey and the thrill behind our perfect combo serve sauce to the desk of web application h4x0r1ng; in short technically ‘penetration testing’. We did our research on most of the topics, and came on with a solution to maintain list of topics which would help provide ways to better tune the research. We maintain our own drafts at our private labs for private use only; however we ended up to conclusions on ‘community releases’ from time to time, so people who couldn’t afford taking up ‘pentest’ classes could find this abandoned post here and research for themselves. It does not end here, we suggest you take up courses on the topics we mention here or at-least look up to our services portal for more vivid information on what we provide. Certainly, it would benefit you the most. Keeping all aside for this post; here are the proposed topics I personally went through which gave me really a deep understanding on what I am supposed to cover (keeping web application pentest in mind!).

HTTP References:

I suggest you take a look to the RFC’s from IETF (Internet Engineering Task Force), they help it when you help yourselves. However the list of the topics compiled to end up matching up with the scope of big task ahead (penetration testing) would fall under these categories, sub-sections and topics. To keep it clean, we would write-up expanded versions of each topics which will be privately maintained by both of us researchers. This doesn’t however is limited to the HTTP 2.0; if you find modifications which is needed to be done, contact us and mention so. The bold text shows materials of interest and studies in relation to cover HTTP keeping ‘security’ in mind.

(A) HTTP Basics.

1.) HTTP/1.0
2.) HTTP/1.1

HTTP 1.1 covers the following sub-categories which still has to be undergoing experimental research and build checklists! all checklists available under version 1.1 are purely over the RFC’s and are drafted by the community over IETF. Regardless of the drafts and the standards use, we will entirely use these drafts to our own advantage to follow-up guidance’s over ‘penetration testing with web application’ and use them only to break them apart. Mitigation’s and fixes come later.


  • HTTP/1.1 Authentication.
  • HTTP/1.1 Caching.
  • HTTP/1.1 Range Requests.
  • HTTP/1.1 Conditional Requests.
  • HTTP/1.1 Semantics and content.
  • HTTP/1.1 Message Syntax and Routing.


We are covering HTTP/1.1 as much as possible because currently we have a wide audience for HTTP/1.1 support. It’s HTML 2.0 which is experimental and has to come shipped with HTML5 based web applications, which is also a part of the scope of the research. We will jump at HTTP 2.0 later at this post. But here are the general HTTP topics to dig!


(B) HTTP deep down.


  1. HTTP “Basic” Authentication.
  2. HTTP “Digest” Access Authentication.
  3. HTTP Encoding Parameter for Basic Authentication.
  4. HTTP Mutual Authentication Protocol.
  5. HTTP Origin-Bound Authentication.

The above topics are deeply studied for HTTP Authentication Schemes which are drafted by the IETF community. Our research goes more deep by inspecting session and state management general topics under HTTP.

  1. HTTP Session Management.
  2. HTTP State Management.

That been said, we will now cover the status code concepts and redirect codes for RESTful services.

  1. HTTP Status Codes.
  2. HTTP Redirect codes for RESTful services.

After we end up with the study of status codes, we must take our inspection to header fields which are security centric to HTTP. Studying header fields over HTTP usually ends up giving us an overall security status and identify entry points (see enumeration later!).

  1. HTTP Accept-POST HTTP header.
  2. HTTP Header field X-Frame-OPTIONS.
  3. HTTP Header filed registrations (this has all the header overview)

There are more; miscellaneous mandatory topics which must bed studied upon studying HTTP closely  shows, they are largely inter-related somehow to web application security concept and should not be ignored. These are..

  1. HTTP Signatures.
  2. HTTP Client Hints.
  3. HTTP Cache-Control Extensions for Stale Content.

Ending an overall inspection of HTTP 1.0 and HTTP 1.1, we will move along to HTTP/2.0 but not before we mention character set and encoding schemes which are allowed on the HTTP protocol.

  • Character Set and Language encoding for HTTP.

We shall now move on to the recently experimental HTTP/2.0 which is proposed (and might be used sooner or later however) in addition to HTTP/1.0 and HTTP/1.1. The following are abstract topics under HTTP/2.0:

  1. HTTP/2.0
  2. WebSocket over HTTP/2.o
  3. Minimal Unauthenticated Encryption (MUE) for HTTP/2.0

Mostly HTML5 is supported/or will be supported accordingly to the HTTP/2.0 standards, but is not limited to as this protocol must be vastly flexible as more and more commercial sites and social arena’s pop’s up! Our HTTP in context to Transport layers must not go a waste study, so here’s it.

  • HTTP Strict Transport Security (HSTS) – Helps in mitigation research studies.

OAuth is mandatory and is related closely to HTTP, so here are the proposed topics to be covered by any serious web security researcher.

  • OAuth 2.0 Message Authentication Code (MAC) Token.

Time to do the maths and start serious working. We will be maintaining serious drafts with us related to outrage of the topics mentioned herein. These drafts will however not/mayn’t reflect the IETF drafts but will comply in parallel to keep ‘web application security centric’ views in reach and within its context. I am glad we could do this and happy that I started this up. Will be back with more. Laters.



IP Resolver for Web Application Bug Hunters!

A tool for digging into the vhosts. Networking could help Web Application Enumeration Phases!

Today, I have a tool for bug hunters who could feel bliss’d using this particular tool. Most of the time, we need IP resolvers to search sub-domain for network exploitation; this isn’t however limited to network exploitation. For web application bug hunters, they need to rely on odd tactics for detection of web application on a specific web server. Here I bring you a new tool, which can auto detect web applications and bring you results. Before hand using this tool, you need to register yourselves with Azure, a Windows Marketplace and get keys to use the Bing API search! here’s how.

Register to:

Search for “Bing API search”, and get the keys (google it around, what good is direct information?); you should get something like following:

ImageWhen you get this, paste this API key to the tool I had provided in the link below!


Start enumerating the sub-domains! you have other options as well, but this gives me the best results in my penetration test work.
Download this tool (Exploit Resolver):

Headache with b1tcypt1on!

Headache with b1tcypt1on!

Windoz b1tcrypt1on made me mad early this morning today. Had to format my external disk to recover the same. I think there should be more documentation related to bde-repair and bde-status because these recovery options are really great but lacks some GUI for the startups. Not only BitLocker Encryption takes long, but if your hard disk suffers from some pre-errors, the encryption stops at a point and when you need to access the disk, neither you can attempt to strike the passoword, nor recover it via bde-repair on Windows 8. Bad windoz with bad BitLocker entities!

  • Does not provide extensive documentation.
  • Bad support community, when asked they say to go to a professional data recovery center. seriously? 😉
  • The problem was only resolved via formatting the external disk, which is a bad idea.
  • The format seemed to be blocked by the conventional method, like right clicking and then formatting.
  • Had to go to the computer management, loaded up virtual disk config, and then deleted the whole disk.
  • Once allocated, I had to then format.
  • In order to recover my data, I had to fire up Stellar NTFS recovery and then recover, recovery isn’t finsihed yes; so can’t say if it would work.
  • The bitlocker encryption failed at a certain point due to disk error never prompted me at the start (should had checked auto before it tries to encrypt, no?)
  • The bitlocker changed my partition from NTFS healthy to RAW, and it was more serious to recover a partition from a RAW disk.
  • There were no disk icons on control panel bitlocker encryption management, and hence no options to unlock!
  • There were access denied and other various errors like “No paramter found” upon a try to access the external disk.
  • bde-repair from -rk or -rp (recovery keys, recovery passwords {48 keys} or even a .bek file) failed.
  • This concludes, chkdsk /f -r fails when you do a bitlocker encrypt and you have a no way out, certainly you have to end up recovering your data after you delete the disk itself from the computer management console and then create the same partition again. Once done, try recovering the data!

I had a lot of data on my external harddisk, some are not coming back as I fear the data which were already encrypted has been lost forever, the rest would however be worth a try and I am going to try recovering all this very afternoon. I had a large shock after I woke up this morning and encountered a bad day. Backup is a must but such large quantity of data could only be saved on a hard disk rather than a optical disk drive. I would ask people not to use MS Bitlocker encryption. TrueCrypt is better!

Continue reading

New blog rants and new bloggy life with more I guess..

Okay so here it goes, people do not really need to know me. I would however post my rants here to log myself somewhere. Might be this gets lost, but hey I had to post everything I do plus with their track records somewhere, no? well yes among various other dead blogs; I had come up with an idea to start a complete new blog (which is this!). I could post here knowing what I have to track for myself and what I have to rant for! Most imporatantly this blog has so many things to do other than personal posts. It has got a coding section category, a penetration test category, others are coming while I am up with an idea to compress all that i learn to a basic blog and come back and learn from them again incase i need to do so.

So, this is 10:55 PM IST exact and I am really starving for certain positive ideas to start from. I have missed more college days than i attend. Apart from that been said, I have priorities, love life seems to be suffering from ocassionally sentimental stuff and there is more to come I guess. However I am keeping up the research as I have to bunk classes to do my own research. To be really honest, college does not help getting anything to the head, it’s sarcastic to say! buy yes. A lot has been going under the hood, I am now going to learn and the IDE’s that support Visual Basic. This being as well on academic schedule will help me do both the research plus the academics. I have to grow over linux more often. I had been going through HTML as a series here as I learn them. I am happening to be learning some of the most serious things in my life. Some of them are technical, others are social as well. I am not that much social tho! to keep everyone reminded; even if you spot me out, I ask you to please don’t re-rant this on other forums or social platform which just does not gives you any better productivity! rather it will only encourage me to delete this blog as rest of the other dead ones. I am dedicated to this blog and hence let this blog survive until my last days.


One does not simply blog!