HTTP - one side of a many sided coinSo on with today's rant......many penetration testers still feel testing an application surrounds testing the HTTP requests and responses between the browser an client; Crawl the application, flag interesting parameters and fuzz using a scanner like OWASP Zap proxy or whatever......
.......We hope the scanner renders the page as a browser sees it. If it doesn't how do we know the reaction of the application is being detected.
One of the hardest things to do when automating scanning is to understand, parse and interpret responses. Sending in data/payloads/attack vectors is the easy part, understanding the response is more difficult. If the response can come from more than one source...now that's a challenge, and a feature of many modern applications.
Our HTTP request can hit the client or the server or either one and be manipulated in many ways on both. So to say one vector/parameter/payload can split into many paths is not far from the truth. many paths mean many possible responses and contexts.
When I deliver training a significant part of it is related to client side encoding to prevent DOM XSS
So to cap this point off...testing Http-Only is bad, there is more to an app than Http requests and responses.
Another issue is testing for client side issues such as XSS (cross site scripting), XFS (cross frame scripting), clickjacking, is very reliant on the browser of choice, the version used etc.
HTML attributes for firefox are different to IE and Chrome are different for various versions and due to this payloads trigger on some browsers and not on others.
The web browser is not only a window to the internet but is fast becoming a shield also to protect users by fulfilling contracts with the web application developers.
Suggestion to make life easier for developers:
By default server HTTP headers should implement:
- X-Frame-Options: SameOrigin
- Content-Security-Policy ,
- Secure (Cookie)
- no-store, no-cache
In the future, If we all use secure browsers should we let the browser take care of client side security issues and not bother to code taking such threats into account? :)
To cap this off......Lets remove dynamic SQL, DES, <128 bit SSL from JAVA
.......Just a thought.