RFR 7095980: Ensure HttpURLConnection (and supporting APIs) don't expose HttpOnly cookies

[Chris Hegarty]

CR 7095980: Ensure HttpURLConnection (and supporting APIs) don't expose 
HttpOnly cookies


The changes use the internal/private java.net.HttpCookie parsing
implementation to filter out HttpOnly cookies from the Set-Cookie and
Set-Cookie2 headers returned in the HTTP protocol handler. With this
change I believe the HTTP protocol suitably protects HttpOnly cookies.

http://cr.openjdk.java.net/~chegar/7095980/webrev.00/webrev/

It reuses the internal java.net.HttpCookie parsing implementation rather 
than trying to maintain two separate parsing implementations. This is a 
little ugly since it is private and in the public java.net namespace, 
but I believe a shared secret is the best approach here. We could have 
moved the implementation itself into sun.net and just made it public, 
but I felt it cleaner to leave it as is.


Thanks,
-Chris.

Review for fix to Bug 7078386

[Brandon Passanisi]

  
  
Hello net-dev.  I was wondering if somebody could review the
proposed fix for the following bug:
Bug URL: http://monaco.sfbay.sun.com/detail.jsf?cr=7078386
  Webrev : http://cr.openjdk.java.net/~michaelm/7078386/webrev.1/

 

The bug is caused by an incorrect format string used in the fscanf
call within enumIPv6Interfaces of
jdk/src/solaris/native/java/net/NetworkInterface.c, which specifies
a two-digit hex number for the network interface index value.  It
has been shown that network interface index values can be more than
255, thus requiring the need to obtain more than two digits.  I
eventually searched through the following linux kernel source file:
linux-source-2.6.32/net/ipv6/addrconf.c

... and it appears the interface index value is being written and an
integer within the function inet6_fill_ifinfo in the following block
of code starting on line 3785:
    if (dev->ifindex != dev->iflink)
          NLA_PUT_U32(skb, IFLA_LINK, dev->iflink);

iflink is defined in linux-source-2.6.32/include/linux/netdevice.h
as an int on line 742:
    /* Interface index. Unique device identifier    */
      int            ifindex;
      int            iflink;

Because of this and because an integer is 32 bits, it appears that
updating the format string to use %08x for the interface index value
seems most correct.

I have tested out this fix successfully in the following ways:
1. I ran the IBM-supplied test programs tapadd and Scope
  to create over 255 address in order to test an interface index
  value of at least three digits.  (These programs will be added to
  the bug report if not present at this time.)  The tapadd program
  is a C test requiring root access that uses tun/tap to create over
  255 interfaces.  Scope is a java program that does a
  NetworkInterface.getByName() on a known interface with an index
  over 255.
  
  2. I modified the Scope program to additionally test all created
  interfaces, not just one interface with an index value over 255. 
  (The original Scope test program just checks a single interface.) 
  This is important to show there aren't regressions.
  
  3. I created another test program using a script to run 'ip'
  commands to create over 255 interfaces.  This script runs in a
  loop using the commands "sudo ip tunnel add..." and "sudo ip -6
  addr add..." to add the interfaces.  Then, I used the Scope
  program to verify the created interfaces.

I wasn't able to create a script that would create a really huge
amount of interfaces because using numbers like 65536 or higher in
my script caused my Ubuntu linux to hang.  So, I'm not quite sure
how to truly test large interface index values like 65536 or more.

Thanks.
-- 
  
  Brandon Passanisi | Principle Member of Technical Staff


Oracle is committed to developing
  practices and products that help protect the environment