Passing parameters in URL

[Paul Rubin]

"Diez B. Roggisch" <deets at nospam.web.de> writes:
> Your web-based chat uses HTTP, no P2P-protocol, and thus the service
> provider *can* log conversations. I don't say he should, I don't say I
> want that, I don't say there are now laws that prevent them from doing
> so, all I say is he *can*.

Sure, my complaint is that the default setup caused this to actually
happen so lots of people using that software were recording user
conversations without realizing it and maybe without caring.  This
is a bad erosion as I see it.

> Then stop logging. Or get a hosting-provider that allows you to
> configure it to strip QUERY_STRINGS from log-entries. And if they
> refuse to, maybe using POST solves the issue.

I did stop logging.  There wasn't an issue with the hosting provider
since I was running the server myself.  But I had to resort to some ugly
software kludge to stop logging those particular strings.  More
frustratingly, I filed a bug report about the issue against the chat
software but the conversation was sort of like the one you and I are
having now.  I just couldn't convince them that there was a problem and
that they should change the default.

> http://www.cyberciti.biz/faq/apache-mod_dumpio-log-post-data/
> So what if they run that?

That sounds like something someone would have to go out of their way to
install and use.  It's not the default.  Of course if someone is
malicious they can do all sorts of nasty stuff.  A coffeeshop that
wanted to mess with me on purpose wouldn't have to do high tech crap
like recording my conversations--they could just poison my coffee.  I
have to trust them to not do this on purpose, but then I see a situation
where their coffee sweetener accidentaly has a harmful chemical, so of
course I'd ask them to do something about it.

> So, for the umpteenth time: data sent over the wire can be recorded. 

And for the umpteenth time, I'm less concerned about "can be" than "is".
POST isn't logged unless you go to some lengths to have it logged.  GET
is logged unless you go to some lengths to prevent it.  It's not enough
in a software deployment to only consider what actions are possible.
It's important to make sure that the default actions are the right ones.

> If they have a positive obligation not to do it, it doesn't matter if
> they run their service over GET or POST.

GET makes it harder for them to fulfill their obligations.  As a
security nerd, I saw what was happening and took measures against it,
but a more typical operator might never notice or care.

There is also the matter of the referer header which an anon mentioned,
though it didn't apply to this particular situation because of how
the application worked.