URLs expose information which we'd like to hide
The parameters passed by GET and, to a lesser extent, the URLs themselves, represent a security issue in one of our systems. One solution, which we tied and have had to back-off from, is to configure the browser window to simply not display the URL and Status lines. The problem there is that the pop-up blockers (now becoming common) interfere. Another, no longer available )-: , would be to exploit the URL hack that MS has just release an IE patch to fix. A partial solution would be to make POST not GET the standard for parameter transmital. Has anyone tried this? I suspect there are all sorts of hidden gotchas. Suggestions?
Dennis Allison wrote:
The parameters passed by GET and, to a lesser extent, the URLs themselves, represent a security issue in one of our systems.
What does that mean? Why do you think its a security issue?
A partial solution would be to make POST not GET the standard for parameter transmital. Has anyone tried this? I suspect there are all sorts of hidden gotchas.
Using POST to send query params instead of GET is trivial. The only gotchas are that using very few browsers handle redirecting POST transactions correctly. This doesn't have anything to do with security though. -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer
Dennis Allison wrote at 2004-2-4 08:09 -0800:
... The parameters passed by GET and, to a lesser extent, the URLs themselves, represent a security issue in one of our systems.
Rethink what you are doing....
.... A partial solution would be to make POST not GET the standard for parameter transmital. Has anyone tried this? I suspect there are all sorts of hidden gotchas.
"POST" requests should not be cached (as they are expected to have side effects). Otherwise, there should be no problems. -- Dieter
Dieter, can you elaborate on this a bit. Passing parameter with the URL (for example, http://foo.goo.com?p1=v1&p2=v2 ) seems to be locked in pretty deeply in the Zope paradigm. What would be your suggestion? On Wed, 4 Feb 2004, Dieter Maurer wrote:
Dennis Allison wrote at 2004-2-4 08:09 -0800:
... The parameters passed by GET and, to a lesser extent, the URLs themselves, represent a security issue in one of our systems.
Rethink what you are doing....
.... A partial solution would be to make POST not GET the standard for parameter transmital. Has anyone tried this? I suspect there are all sorts of hidden gotchas.
"POST" requests should not be cached (as they are expected to have side effects). Otherwise, there should be no problems.
-- Dieter
Dennis Allison wrote at 2004-2-4 13:51 -0800:
Dieter, can you elaborate on this a bit. Passing parameter with the URL (for example, http://foo.goo.com?p1=v1&p2=v2 ) seems to be locked in pretty deeply in the Zope paradigm. What would be your suggestion?
HTML is not designed to be secure against curious users.... When you try to hide parameters, I will use a TCPLogger to see what is on the wire. When you use HTTPS, I will analyse the HTML source to determine your secrets.
On Wed, 4 Feb 2004, Dieter Maurer wrote:
Dennis Allison wrote at 2004-2-4 08:09 -0800:
... The parameters passed by GET and, to a lesser extent, the URLs themselves, represent a security issue in one of our systems.
Rethink what you are doing....
-- Dieter
Dennis Allison wrote:
Dieter, can you elaborate on this a bit. Passing parameter with the URL (for example, http://foo.goo.com?p1=v1&p2=v2 ) seems to be locked in pretty deeply in the Zope paradigm. What would be your suggestion?
When submitting a form, it makes no difference to Zope the method you use. In fact I almost always use POST, save when I want to see the parameters for debugging purposes. Only when you have a link that must provide parameters must you use URL parameters. The cases where this is necessary are rare but do exist (usually but not always for aesthetic purposes), and in this case, there's no way to hide information in the link, though you can try various key-based or hashing schemes: see the PasswordResetTool in the Collective for such a technique. --jcc -- "He who fights with monsters should look to it that he himself does not become a monster. And when you gaze long into an abyss the abyss also gazes into you."
participants (4)
-
Dennis Allison -
Dieter Maurer -
J Cameron Cooper -
Jamie Heilman