The COOKIE restriction simply removes cookies in both directions, rather than refusing requests to set and get them within the HTTP protocol; this behavior often breaks access to pages that are viewable by simply refusing the cookies, which is how today's modern browsers work.
JAR validation facilities acquire the hash and signature values that are added to the configuration.
ACTIVEX filtering currently blocks certain types of Java content and does not support certain types of FTP downloads. It multiplexes and demultiplexes URL references that contain explicit port numbers (for example: http://foo.com:12345/), which is good because without the proxy, and lacking a proper www state engine in the kernel, you must either forgo access to such URLs or allow insecure tcpall outbound from all browser hosts.
The proxy provides the option to allow tcpall from the routing-mode Screen outbound, which, in conjunction with the HTTP proxy, affords access to such URLs through the proxy.
However, the HTTP proxy can also have untoward security problems by permitting client host browsers to gain outbound access to systems and ports for which you did not intend.
For example:
# ssadm edit configedit> add address sensitive1 HOST 222.1.1.1edit> add address sensitive2 HOST 222.1.2.2edit> add address sensitive GROUP { sensitive1 sensitive2 }edit> add address browser HOST 222.1.3.3edit> add address router HOST 222.1.254.254edit> add address qe0 RANGE 222.1.254.0 222.1.254.255edit> add address qe1 RANGE 222.1.1.0 222.1.1.255edit> add address qe2 RANGE 222.1.2.0 222.1.2.255edit> add address qe3 RANGE 222.1.3.0 222.1.3.255edit> add address outside GROUP { } { qe1 qe2 qe3 localhost router }edit> add rule sensitive-stuff sensitive sensitive ALLOWedit> add rule telnet sensitive router ALLOWedit> add rule telnet localhost router ALLOWedit> add rule telnet localhost sensitive ALLOWedit> add rule www browser "*" ALLOW PROXY_HTTP |
It appears as if sensitive is well protected, but, in fact, the browser can cause the HTTP proxy to access the telnet service of both router and sensitive.
Including the following rule worsens the configuration situation:
edit> add rule "common services" localhost "*" ALLOW |
Such a rule affords browser access to any TCP service in any rule with the source localhost (unless contrary DENY rules are created).