Passing parameters in URL

[Bruno Desthuilliers]

Diez B. Roggisch a écrit :

Am 03.02.10 19:11, schrieb John Bokma:

You should *never* say never, because there might be situations where
exceptions from rules are valid. This is one such cases.

Oh yes ?

Making this a
post means that you need to resort to javascript to populate & submit a
hidden HTML-form.

I beg your pardon ???? This is total nonsense. Hopefully you don't need
any js to emit a post request from a browser ! The only thing you need
to do is to use a form and submit input instead.

 

[Bruno Desthuilliers]

Paul Rubin a écrit :

There's also the issue that a user can change "123" to "125" and
possibly mess with someone else's resource,
unless you use some server
side authentication.

What I said IIRC.

Or just seeing how often the numbers change could
reveal patterns about what other users are doing. I always think it's
best to encrypt anything sensitive like that, to avoid leaking any info.

Depends on how "sensitive" it really is.

 

[Bruno Desthuilliers]

Bruno Desthuilliers a écrit :

Diez B. Roggisch a écrit : (snip)

I beg your pardon ???? This is total nonsense.

Sorry, posted too fast, John alredy adressed this.

 

[Steve Holden]

Those are not comparable. IMAP is a storage service, and groups,
facebook, and twitter are publishing systems (ok, I've never understood
quite what Google Wave is). Yes, by definition, your voice mail
provider (like IMAP) has to save recordings of messages people leave
you, but that's a heck of a lot different than your phone carrier
recording your real-time conversations. Recording live phone
conversations by a third party is called a "wiretap" and doing it
without suitable authorization can get you in a heck of a lot of
trouble.

Unless you happen to be following the illegal instructions of the
President of the United States, in which case Congress will
retro-actively alter the law to void your offenses and provide you with
legal immunity for your wrong-doing. Assuming you are a large telephone
company and not a private individual.

Well, the extra logging of GET parameters is not inherent to the
protocol, but it's an accidental side effect that server ops may have to
watch out for.


I'm not sure what you mean by that. Obviously if users want to record
their own conversations, then I can't stop them, but that's much
different than a non-participant in the conversation leaving a recorder
running 24/7. Is that so hard to understand?

Interception from the middle is addressed by SSL, though that relies on
the PKI certificate infrastructure, which while somewhat dubious, is
better than nothing.


I certainly didn't feel that saving or not saving client conversations
on the server side was up to my discretion. When I found that the
default server configuration caused conversations to be logged then I
was appalled.

Do you think the phone company has the right to record all your phone
calls if they feel like it (absent something like a law enforcement
investigation)? What about coffee shops that you visit with your
friends? It is not up to their discretion. They have a positive
obligation to not do it. If you think they are doing it on purpose
without your authorization, you should notify the FBI or your
equivalent, not just "don't use it". If they find they are doing it
inadvertently, they have to take measures to make it stop. That is the
situation I found myself in, because of the difference in how servers
treat GET vs. POST.

A lot will depend on the terms of service of the network supply
contract. Most vendors take pains to ensure that such "innocent" logging
(i.e. the maintenance by their servers of logging information, which may
under subpoena or similar legal coercion be given up to law enforcement
authorities as "business records") is permitted. If you have signed the
contract, then they have the right to log that data.

Caveat emptor.

regards
Steve

 

[John Bokma]

Am 04.02.10 01:42, schrieb John Bokma:
[..]

Maybe you should think about what happens if someone posts:
<img src="http://example.com/item_delete?id=123"> to a popular forum...

And the difference to posting

from urrlib2 import open
from urllib import encode

open("http://example.com/item_delete", data=encode([("id", "123")]))

to that same public "hacker" forum is exactly what?

Imagine that a user of example.com, logged in at example.com (i.e. with
a valid session ID in a cookie), visits the aforementioned (by me)
forum, and that he has an item 123. It will be deleted.

If your webapp happens to allow item_delete to be called without
authentication & authorization, then *that's* your problem.

You now understand that *with* a & a a GET request can be *still* harmful?

 

[Diez B. Roggisch]

Am 04.02.10 18:22, schrieb John Bokma:

Am 04.02.10 01:42, schrieb John Bokma:
[..]

Maybe you should think about what happens if someone posts:
<img src="http://example.com/item_delete?id=123"> to a popular forum...

And the difference to posting

from urrlib2 import open
from urllib import encode

open("http://example.com/item_delete", data=encode([("id", "123")]))

to that same public "hacker" forum is exactly what?

Imagine that a user of example.com, logged in at example.com (i.e. with
a valid session ID in a cookie), visits the aforementioned (by me)
forum, and that he has an item 123. It will be deleted.

The webapp must be actually preventing the processing of GET-requests
for the aciton in question. This isn't the case by default for many of
them, in fact at least e.g. TurboGears, as well as PHP offer you ways to
treat GET and POSTvars the exact same way. So unless the programmer is
aware of this potential problem, it won't help.

And in the same way one can embed a form with a post-action that leads
to the full http://example.com-url into an external page. So it is
equally as dangerous. Yes, links are easier, no doubt about that. But
POST doesn't magically make you safe from those kinds of attacks.

The only way to prevent this are short-lived sessions, or action-tokens
of some kind, as Paul mentioned before.

Diez

 

[Alan Harris-Reid]

Many thanks to all those who replied to my question and clearing-up the
differences between GET and POST. I think I know what to do now - if
not, I'll be back

Regards,
Alan