Re: SSL weakness affecting links from pa
Tom Weinstein wrote:
This particular feature (the HTTP referer header) has nothing to do with corporations "having their way" with users. It was created so that web authors could put "back" buttons on their pages. The security problem arises when stupid CGI authors use GET forms to transfer sensitive information. This is a security hole in the web site, not in the browser. The browser follows the HTTP specification. If you have a problem with that, contact the author of that specification. Or, better yet, contact the web site (as far as I know, there are none) that has this security hole.
Stupid programmers abound even in large corporations. Bugs, patches and security holes are now normal everyday things. I agree with Toto. Companies should take more responsability in the programs they produce. Especially nowadays when a lot of people without any computer background or insight into the dangers are accessing the Net. Why does Netscape (and microsoft) warn users about secure and insecure forms? So they can say "I told you so!" when you get screwed by someone. Same thing goes for the GET method. Whatever a "stupid CGI author" does has little bearing on the issue. It's like saying the tire fell off my car because the person who built the road to spec ("GET" is allowed) is to blame not the car maker. I should be warned about certain roads by the car maker. If "GET" is allowed but unsecure YOU should warn me! Admit it! It did not occur to your programmers to warn about access to "GET" forms like it occurred to them to warn about http references inside a https-accessed document. Now we have to live with it. And you say "stupid CGI authors". What if they did it on purpose? Are you going to say "then its stupid web users"? I'd really like to hear you say that in public!
In the eyes of some, the referer header is a privacy violation. It allows a site to see what site you visited before coming there. In the case of Navigator, we ONLY send the referer header when you click on a link. Not when you select a bookmark. Not when you type a URL into the location field. This allows web sites to see who links to them. I think that's something that a web author is entitled to know.
NO WAY! The web author is NOT entitled to know where I came from. So if you go to Sears the saleperson is entitled to know you came from JCPenney's? If so, then I am just as much entitled to not tell him or at least entitled to know that there's a sign on my back that says where I came from. How many web users are aware of the HTTP REFERRER header? Not many, especially if they have not read the specs or looked at the logs from a web server. As an adminsitrator I AM NOT ENTITLED to that info.
So, you think we're doing something bad. Why don't you tell me what you think we should do?
Accept responsibility? Ok, that's wishful thinking. How about not blaming others? How about warning your users? You didn't do it in this case. If you do then you can say "I told you so!" Art Grapa agrapa@banamex.com
ARTURO GRAPA YSUNZA writes:
Tom Weinstein wrote:
This particular feature (the HTTP referer header) has nothing to do with corporations "having their way" with users. It was created so that web authors could put "back" buttons on their pages. The security problem arises when stupid CGI authors use GET forms to transfer sensitive information. This is a security hole in the web site, not in the browser. The browser follows the HTTP specification. If you have a problem with that, contact the author of that specification. Or, better yet, contact the web site (as far as I know, there are none) that has this security hole.
Stupid programmers abound even in large corporations. Bugs, patches and security holes are now normal everyday things. I agree with Toto. Companies should take more responsability in the programs they produce.
No, specification authors should take more responsibility in the specs that they produce. The HTTP spec's use of GET is insecure. Specification writers should realize that people will follow their specs, and should be thinking of security and privacy issues as they are beig written.
In the eyes of some, the referer header is a privacy violation. It allows a site to see what site you visited before coming there. In the case of Navigator, we ONLY send the referer header when you click on a link. Not when you select a bookmark. Not when you type a URL into the location field. This allows web sites to see who links to them. I think that's something that a web author is entitled to know.
NO WAY! The web author is NOT entitled to know where I came from. So if you go to Sears the saleperson is entitled to know you came from JCPenney's? If so, then I am just as much entitled to not tell him or at least entitled to know that there's a sign on my back that says where I came from. How many web users are aware of the HTTP REFERRER header? Not many, especially if they have not read the specs or looked at the logs from a web server. As an adminsitrator I AM NOT ENTITLED to that info.
Why not? It's a useful tool to find out who has linked to you. On the other hand, it _is_ a privacy concern, and I don't want to send it to sites I visit. So I included an option blocking the Referrer tag in Cookie Jar, the cookie-blocking program I wrote. I'd like to think that writing it helped push Netscape into supporting better options for cookies (see rfc2109) and into adding this option for not sending Referrer but I'm sure there were many other louder calls for the same thing.
Accept responsibility? Ok, that's wishful thinking. How about not blaming others? How about warning your users? You didn't do it in this case. If you do then you can say "I told you so!"
Users need to educate themselves. Even a fairly security and privacy concious company like Netscape still has exectutives who feel as though they have to answer to the bottom line and who will sacrifice consumer privacy to get there if they feel that the advantages outweigh the risks. Netscape has consistently led industry in realizing and fixing and admitting security holes and privacy issues, largely due to the effort of Jeff and the rest of their security group in educating upper management on those issues and making them realize their importance. However I am not willing to bet my privacy on Netscape's good will, as it could turn at any time. The way to real privacy is to educate oneself. Demanding companies to "fix it" is lame and ineffectual. You have the technology- fix it yourself! Distribute your code. Make the companies look bad. Educate the sheeple. But asking companies to look out for your privacy is a waste of time. -- Eric Murray ericm@lne.com Privacy though technology! Network security and encryption consulting. PGP keyid:E03F65E5
participants (2)
-
ARTURO GRAPA YSUNZA -
Eric Murray