Description

i will mentions the problems and the solutions and references to read further about.

1- X-Frame-Options header is not included in the HTTP response to protect against 'clickjacking' attacks

Solution

Most modern web browsers support the X-Frame-Options HTTP header , Ensure its set on all web pages return by the site (if you expect the page to be framed only by pages on your server (e.g its part of a FRAMESET) then you will want to use SAMEORIGIN, otherwise if you never expect the page to be framed , you should use DENY. ALLOW-FROM allows specific websites to frame the web page in supported web browsers.

The X-XSS-Protection HTTP resonse header is currently supported on the internet explorer , chrome , safari (webKit).
NOTE that this alert is only raised if the response body could potentially contain an XSS payload
(with a text-based content type, with a non-zero lenght).

4- Private IP Disclosure , A private IP such as 10.x.x.x or 172.x.x.x or 192.168.x.x shouldnt been found in HTTP response body. The information might be helpful for further attacks targeting internal systems.

IP founds:-

192.168.1.1

solution

Remove the private IP address from the HTTP response body. For comments, use JSP/ASP comment instead of HTML/javaScript comment which can be seen by client browsers.

The Anti-MIME-Sniffing header X-Content-Type-Options was not set to 'nosnif'. This allow older versions of internet explorer and chrome to perform MIME-Sniffing on the response body. potentially causing the response body to be interpreted and displayed as a content type other than the declared content type. Current (early 2014) and legacy versions of Firefox will use the declared content type (if one is sey), rather than performing MIME-Sniffing.

further info

This issue still applies to error type pages (401, 403, 500, etc) as those pages are often still affected by injection issues, in which case there is still concern for browsers sniffing pages away from their actual content type.
At "High" threshold this scanner will not alert on client or server error responses

solution

Ensure that the application/web server sets the Content-Type header appropriately, and that it sets the X-Content-Type-Options header to 'nosniff' for all web pages.

If possible, ensure that the end user uses a standards-compliant and modern web browser that does not perform MIME-sniffing at all, or that can be directed by the web application/web server to not perform MIME-sniffing.

Subtickets

Change History (6)

We do provide the headers for 1) and 3). Are you even testing? If they are missing on a particular page, please give the url.
2) Would be a pain for users that want it. They can disable autocomplete in their browser if they like.
4) That should only happen if you are local anyway. I don't see the problem here.
5) (labeled as another 3) is the only item worth looking into.

2) Would be a pain for users that want it. They can disable autocomplete in their browser if they like.

yeah but why i did suggested this, because in theoretical/imaginary way:-

since i2p is a unidirectional connection , so connection to happen its like me then X then Y then ..etc then website so let us put it this way:-

ME-X-Y-Z-destination (website)-G-K-ME

if we assume that Y or any point is an attacking point which is used as a password collector packet on the moving traffics = then he will collect as much emails and passwords as possible. so thats why i suggested to turn off this feature even if the user is going to suffer typing things but this is the old days style of typing passwords now there r keepassX and similar tools which can save ur 40 length password and u can copy/paste it with one click.

(but remember this is all theoretical , i dont have evidences. tho, that doesnt mean it might not happen and the only way if u want to make sure for this to happen or not then someone has experts in i2p traffics and exploitation of the same time in order to this attack)

4) That should only happen if you are local anyway. I don't see the problem here.

2) None of your response addresses that it should be the user's decision in his browser setup

4) If you're insisting this is a problem, please provide URLs where this happens. It seems like you're just copy and pasting stuff spit out from some analysis tool. Anybody can do that. If you can't provide a little context, the actual URLs, and some solid justification then what's the point. The console is for administration. The person accessing it knows what the IP is and listing IPs on there, even RFC 1918 IPs, is not a security issue. Please understand what the console is for. Copy/paste of some general-purpose analyzer isn't always helpful.