4367460 removes the heuristics from NBS. However, for some use cases, the heuristics can be beneficial, both for Firefox-like and Chrome-like browsers.
We should go through the errors at
and propose weights that reflect how much information the error leaks and how common the error is.
So for example 404 adds 1 to the hostStatistics at
|
currentHost[targetUrl.hostname]["httpErrors"] += 1; |
while maybe 406 could be a sign of some incompatibility between the client and the server. So I propose something like:
var httpErrorList = {
...
404:1,
405:0.5,
406:0.1,
...
...
currentHost[targetUrl.hostname]["httpErrors"] += httpErrorList[headers.statusCode];Going back to 401, it leaks that the server exists but once known, there is not much to be learn in respect to the proxy discovery attack. That is the reason we decided to omit 401. However, blocking a server with excessive 401 errors makes sense because it might be a distributed password cracking attack. Suppose a malicious server distributes to a connected client passwords and lets the clients do the dirty work of connecting to the victim server. This way, server logs will show the browser proxy IP address and not the real attacker. If we pick weight 0.01 for 401 that means 1000 attempts. Does it make sense to reintroduce 401 and similar errors with a smallish weight? If so, does it make sense to have something like that for Firefox as well?
We should go through potential attacks that the heuristics can block and try to mitigate them.
The issue was originally a part of #62.
4367460 removes the heuristics from NBS. However, for some use cases, the heuristics can be beneficial, both for Firefox-like and Chrome-like browsers.
We should go through the errors at
jsrestrictor/chrome/http_shield_chrome.js
Line 41 in 0ff5acc
So for example 404 adds 1 to the
hostStatisticsatjsrestrictor/chrome/http_shield_chrome.js
Line 171 in 0ff5acc
Going back to 401, it leaks that the server exists but once known, there is not much to be learn in respect to the proxy discovery attack. That is the reason we decided to omit 401. However, blocking a server with excessive 401 errors makes sense because it might be a distributed password cracking attack. Suppose a malicious server distributes to a connected client passwords and lets the clients do the dirty work of connecting to the victim server. This way, server logs will show the browser proxy IP address and not the real attacker. If we pick weight 0.01 for 401 that means 1000 attempts. Does it make sense to reintroduce 401 and similar errors with a smallish weight? If so, does it make sense to have something like that for Firefox as well?
We should go through potential attacks that the heuristics can block and try to mitigate them.
The issue was originally a part of #62.