Http-Only is not secure [testing]

简介: Its been a while since i posted. I've been bogged down with code reviews and training but even...
Its been a while since i posted. I've been bogged down with code reviews and training but even when you deliver training you learn something new. This is particularly true when training developers keen to learn secure development. The conversations during the course tend to be more about building than breaking....


HTTP - one side of a many sided coin
So 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.


Many scanners parse HTML pretty well but when it comes to javascript/jquery/client-side-code-execution that's where they fall over.
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
This type of attack can't be detected with HTTP analysis in the traditional sense. Javascript parsing is required and tools like  dominator  do this pretty well but there is very little in the commercial field to tackle this type of assessment at scale.


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 browser protects us from lots of security issues like cross domain framing attacks, inline javascript attacks things like  content security policy  and  X-FRAME-OPTIONS  tell the browser not to accept or react to certain contexts.


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 , 
  • HttpOnly, 
  • Secure (Cookie)
  • Strict-Transport-Security
  • 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
and inline javascript from all browsers (data and code getting mixed).....what would we fix is we did this???

.......Just a thought.
目录
相关文章
|
7天前
|
网络协议 安全 网络安全
Introduction to the HTTP and HTTPS Protocol
HTTP protocol is the foundation of the Internet, and HTTPS is the secure version of HTTP. HTTP is an application layer protocol based on TCP/IP protocol. It does not involve packet (packet) transmission, mainly specifying the communication format between the client and the server, and the default po
58 25
|
4月前
|
安全 应用服务中间件 网络安全
修复HTTPS升级后出现 Mixed Content: The page at 'https://xxx' was loaded over HTTPS, but requested an insecure frame 'http://xxx'. This request has been blocked; the content must be served over HTTPS. 的问题
修复HTTPS升级后出现 Mixed Content: The page at 'https://xxx' was loaded over HTTPS, but requested an insecure frame 'http://xxx'. This request has been blocked; the content must be served over HTTPS. 的问题
|
Docker 容器
http: server gave HTTP response to HTTPS client解决方案
http: server gave HTTP response to HTTPS client解决方案
942 0
|
SQL 缓存 负载均衡
Web Security 之 HTTP Host header attacks(上)
Web Security 之 HTTP Host header attacks
771 0
|
缓存 安全 网络协议
Web Security 之 HTTP Host header attacks(下)
Web Security 之 HTTP Host header attacks
193 0
|
运维 PHP
php curl Received HTTP code 403 from proxy after CONNECT
php curl Received HTTP code 403 from proxy after CONNECT
1139 0
curl: (1) Protocol "https" not supported or disabled in libcurl
curl: (1) Protocol "https" not supported or disabled in libcurl
326 0
|
Web App开发 缓存 安全
HTTP Strict Transport Security实战详解
HTTP Strict Transport Security (通常简称为HSTS) 是一个安全功能,它告诉浏览器只能通过HTTPS访问当前资源, 禁止HTTP方式。 0×01. Freebuf百科:什么是Strict-Transport-Security 我摘自owasp上的一段定义: ...
2579 0

热门文章

最新文章