«

I have a web-page where each row in a grid has edit/delete buttons to
enable the user to maintain a selected record on another page. The
buttons are in the form of a link with href='/item_edit?id=123', but
this string appears in the URL and gives clues as to how to bypass the
correct sequence of events, and could be risky if they entered the URL
directly (especially when it comes to deleting records).

Is there another way of passing a record-id to a method
a) without it appearing in the URL?
b) without the user being able to fathom-out how to attach which id to
which URL?

As each link contains row-id, I guess there is nothing to stop someone
from getting the id from the page source-code. Is it safe to use the
above href method if I test for authorised credentials (user/password
stored as session variables, perhaps?) before performing the edit/delete
action?

I am currently using CherryPy 3.2, but I guess the theory could apply to
any HTTP framework or web app..

Any help would be appreciated.
Alan Harris-Reid

Alan Harris-Reid <> writes:

> I have a web-page where each row in a grid has edit/delete buttons to
> enable the user to maintain a selected record on another page. The
> buttons are in the form of a link with href='/item_edit?id=123', but
> this string appears in the URL and gives clues as to how to bypass the
> correct sequence of events, and could be risky if they entered the URL
> directly (especially when it comes to deleting records).

You should *never* use a GET request to do actions like deleting
records. You already are aware of it being risky, so don't do this. You
should use GET for getting information, and POST for modifying information.

> Is there another way of passing a record-id to a method
> a) without it appearing in the URL?

Use a POST request. Note that the user still has to select something,
and that this information is send by the browser, and hence the user can
see this information (and maybe others), and repeat the action with, for
example, a Python program.

> b) without the user being able to fathom-out how to attach which id to
> which URL?

I am not sure what you want to prevent here. If you're afraid that user
A can delete things that belong user B, than "hiding" things or making
them "hard to guess" are not going to help much. If you have several
users, you must use some login procedure (and sessions).

> As each link contains row-id, I guess there is nothing to stop someone
> from getting the id from the page source-code. Is it safe to use the
> above href method if I test for authorised credentials (user/password
> stored as session variables, perhaps?) before performing the
> edit/delete action?

Yes. But still make sure that session ids are not easy to guess, and
expire. And make very sure that session ids can't leak to others.

Moreover, each time you modify a database use POST. One could argue to
also use POST for logging out, otherwise another site might be able to
log your users out if they visit that site.

--
John Bokma j3b

Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development

Alan Harris-Reid <> writes:
> As each link contains row-id, I guess there is nothing to stop someone
> from getting the id from the page source-code. Is it safe to use the
> above href method if I test for authorised credentials (user/password
> stored as session variables, perhaps?) before performing the
> edit/delete action?

Well, if it's really ok for them to delete records programmatically even
if it's ok for them to delete through the web site. I'd probably
encrypt the post parameters if this was a concern.

Am 03.02.10 19:11, schrieb John Bokma:
> Alan Harris-Reid<> writes:
>
>> I have a web-page where each row in a grid has edit/delete buttons to
>> enable the user to maintain a selected record on another page. The
>> buttons are in the form of a link with href='/item_edit?id=123', but
>> this string appears in the URL and gives clues as to how to bypass the
>> correct sequence of events, and could be risky if they entered the URL
>> directly (especially when it comes to deleting records).
>
> You should *never* use a GET request to do actions like deleting
> records. You already are aware of it being risky, so don't do this. You
> should use GET for getting information, and POST for modifying information.

You should *never* say never, because there might be situations where
exceptions from rules are valid. This is one such cases. Making this a
post means that you need to resort to javascript to populate & submit a
hidden HTML-form. Just for the sake of a POST.

And there are people who say "you should *never* write web-apps that
only work with enabled javascript"... catch 22.

Also, your claim of it being more risky is simply nonsense. GET is a
tiny bit more prone to tinkering by the average user. But calling this
less risky is promoting security by obscurity, at most.

Diez

"Diez B. Roggisch" <> writes:
> Also, your claim of it being more risky is simply nonsense. GET is a
> tiny bit more prone to tinkering by the average user. But calling this
> less risky is promoting security by obscurity, at most.

GET parameters also tend to get recorded in the http logs of web proxies
and web servers while POST parameters usually aren't. This was an
annoyance in a web chat package I fooled with for a while. Because the
package sent user messages by GET, if I ran the software the way the
developers set it up, the contents of all the user conversations stayed
in my server logs. I was unable to convince the chat package
maintainers that this was a bug. I ended up doing some fairly kludgy
hack to prevent the logging.

Am 03.02.10 19:01, schrieb Alan Harris-Reid:
> I have a web-page where each row in a grid has edit/delete buttons to
> enable the user to maintain a selected record on another page. The
> buttons are in the form of a link with href='/item_edit?id=123', but
> this string appears in the URL and gives clues as to how to bypass the
> correct sequence of events, and could be risky if they entered the URL
> directly (especially when it comes to deleting records).
>
> Is there another way of passing a record-id to a method
> a) without it appearing in the URL?

You can populate an invisible HTML-form with the values, and submit that
- of course you need javascript for this.

But this doesn't increase security a bit. Using an extension to FF such
as HTTP live headers, it's easy enough to figure out what parameters are
passed, and simply forge a request.


> b) without the user being able to fathom-out how to attach which id to
> which URL?

Paul already mentioned that - you can create a server-side,
session-stored action-item that is identified by a hash of some sort.
Then use that hash as parameter.

But I'd say you should instead make sure that your serve actions perform
authorization checking before performing any operations. Then you don't
need to worry - even guessing a hash argument won't work then.

>
> As each link contains row-id, I guess there is nothing to stop someone
> from getting the id from the page source-code. Is it safe to use the
> above href method if I test for authorised credentials (user/password
> stored as session variables, perhaps?) before performing the edit/delete
> action?

You should of course always do that. Every http-action except login
should be guarded (unless you allow anonymous access of course).

Diez

Am 03.02.10 23:09, schrieb Paul Rubin:
> "Diez B. Roggisch"<> writes:
>> Also, your claim of it being more risky is simply nonsense. GET is a
>> tiny bit more prone to tinkering by the average user. But calling this
>> less risky is promoting security by obscurity, at most.
>
> GET parameters also tend to get recorded in the http logs of web proxies
> and web servers while POST parameters usually aren't. This was an
> annoyance in a web chat package I fooled with for a while. Because the
> package sent user messages by GET, if I ran the software the way the
> developers set it up, the contents of all the user conversations stayed
> in my server logs. I was unable to convince the chat package
> maintainers that this was a bug. I ended up doing some fairly kludgy
> hack to prevent the logging.

If somebody happens to have access to a proxy & it's logs, he can as
well log the request body.

Don't get me wrong, I don't want to propagate the use of GET as one and
only method for parameter passing. But whatever is transmitted clear
text over the wire is subject to inspection of all hops in between. Use
SSL if you bother.

Diez

"Diez B. Roggisch" <> writes:
> If somebody happens to have access to a proxy & it's logs, he can as
> well log the request body.

I'm not talking about a malicious server operator. In this situation, I
was the server operator and I didn't want to be recording the
conversations. I had to go out of my way to stop the recording. SSL
doesn't help and in fact I was using it, but web server logging happens
after the SSL layer. I suppose SSL would help against a malicious
proxy.

Many people back in those days (before AJAX became a buzzword du jour)
wanted to do encryption on the client in java or javascript, but that
was almost unworkably kludgy, and SSL was the only approach that made
any sense. It might be easier now that the javascript API's are richer
and the interpreters are faster.

Am 03.02.10 23:35, schrieb Paul Rubin:
> "Diez B. Roggisch"<> writes:
>> If somebody happens to have access to a proxy& it's logs, he can as
>> well log the request body.
>
> I'm not talking about a malicious server operator. In this situation, I
> was the server operator and I didn't want to be recording the
> conversations. I had to go out of my way to stop the recording. SSL
> doesn't help and in fact I was using it, but web server logging happens
> after the SSL layer. I suppose SSL would help against a malicious
> proxy.

Well, we actually implemented POST-parameter logging (inside the
WSGI-app), because we *want* all parameters users pass. They end up in
the application anyway, and aid debugging. Of course we blind sensitive
parameters such as passwords & creditcard numbers.

Of course only information not gathered is really safe information. But
every operation that has side-effects is reproducable anyway, and if
e.g. your chat-app has a history, you can as well log the parameters.

Diez

"Diez B. Roggisch" <> writes:
> Of course only information not gathered is really safe
> information. But every operation that has side-effects is reproducable
> anyway, and if e.g. your chat-app has a history, you can as well log
> the parameters.

No I can't. The chat-app history would be on the client, not the
server, so I'd have no access to it. Put another way: as server
operator, I'm like the owner of a coffee shop. I can't stop patrons
from recording their own conversations with each other, and it's not
even really my business whether they do that. But it would be
outrageous for the shop owner to record the conversations of patrons.