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: https://datatracker.ietf.org/doc/search/?name=HTTP&activeDrafts=on&rfcs=on

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

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

 

 

Advertisements

Looking for intellectual opinions. Feedbacks are welcome!

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s