Can anyone interpret this paragraph from "Connected: An Internet Encyclopedia"?

This is from Chapter 12.2 Safe Methods

http://www.freesoft.org/CIE/RFC/1945/70.htm

"In particular, the convention has been established that the GET and
HEAD methods should never have the significance of taking an action
other than retrieval. These methods should be considered "safe." This
allows user agents to represent other methods, such as POST, in a
special way, so that the user is made aware of the fact that a
possibly unsafe action is being requested."

What does this mean? Thank you.

Re: Can anyone interpret this paragraph from "Connected: An Internet Encyclopedia"?

Reporter writes:

> This is from Chapter 12.2 Safe Methods
>
> http://www.freesoft.org/CIE/RFC/1945/70.htm
>
> "In particular, the convention has been established that the GET and
> HEAD methods should never have the significance of taking an action
> other than retrieval. These methods should be considered "safe."

GET and HEAD commands sent to a web server should do nothing but read
some stuff. They shouldn't change anything. Furthermore, they
aren't generally sending any info to the web server across a (possibly
unencrypted) connection other than the request itself.

Some GET requests however do send parameters in the URL, sometimes
stupidly.

> This allows user agents

"user agents" think "web browsers"

> to represent

implement

> other methods, such as POST, in a special way, so that the user is
> made aware of the fact that a possibly unsafe action is being
> requested."

POST is generally the request a web browser is doing behind the scenes
when say, you press SUBMIT on a web form a login form, credit card
details form, search box, whatever.

The RFC is suggesting here that warning box you get when you first
submit a form (that uses the POST method) on a new computer or with a
new web browser that warns you that you are about to submit form field
details and send them over an unencrypted link (in the case of a
non-ssl site) and that other people can view them.


At least that's one opinion of what this all means, anyway.

Best Regards,d
--
Todd H.
http://www.toddh.net/

Re: Can anyone interpret this paragraph from "Connected: An Internet Encyclopedia"?

On Jul 1, 12:59 pm, comph...@toddh.net (Todd H.) wrote:
> Reporter writes:
> > This is from Chapter 12.2 Safe Methods
>
> >http://www.freesoft.org/CIE/RFC/1945/70.htm
>
> > "In particular, the convention has been established that the GET and
> > HEAD methods should never have the significance of taking an action
> > other than retrieval. These methods should be considered "safe."
>
> GET and HEAD commands sent to a web server should do nothing but read
> some stuff. They shouldn't change anything. Furthermore, they
> aren't generally sending any info to the web server across a (possibly
> unencrypted) connection other than the request itself.
>
> Some GET requests however do send parameters in the URL, sometimes
> stupidly.
>
> > This allows user agents
>
> "user agents" think "web browsers"
>
> > to represent
>
> implement
>
> > other methods, such as POST, in a special way, so that the user is
> > made aware of the fact that a possibly unsafe action is being
> > requested."
>
> POST is generally the request a web browser is doing behind the scenes
> when say, you press SUBMIT on a web form a login form, credit card
> details form, search box, whatever.
>
> The RFC is suggesting here that warning box you get when you first
> submit a form (that uses the POST method) on a new computer or with a
> new web browser that warns you that you are about to submit form field
> details and send them over an unencrypted link (in the case of a
> non-ssl site) and that other people can view them.
>
> At least that's one opinion of what this all means, anyway.
>
> Best Regards,d
> --
> Todd H.http://www.toddh.net/

Todd, thank you very much.

- Sam -

Re: Can anyone interpret this paragraph from "Connected: An Internet Encyclopedia"?

Todd H. wrote:
> GET and HEAD commands sent to a web server should do nothing but read
> some stuff. They shouldn't change anything.

Oh yes, they can. They can change some state in the web server, why not?

Yours,
VB.
--
"Es muss darauf geachtet werden, dass das Grundgesetz nicht mit Methoden
geschützt wird, die seinem Ziel und seinem Geist zuwider sind."

Gustav Heinemann, "Freimütige Kritik und demokratischer Rechtsstaat"

Re: Can anyone interpret this paragraph from "Connected: An InternetEncyclopedia"?

Volker Birk wrote:

> Todd H. wrote:
>> GET and HEAD commands sent to a web server should do nothing but read
>> some stuff. They shouldn't change anything.
>
> Oh yes, they can. They can change some state in the web server, why not?


Read the RFC: They shouldn't, and if you don't follow this, you run into a
big load of problems like inconsistencies on load errors or Cross Site
Request Forgery attacks.

Re: Can anyone interpret this paragraph from "Connected: An Internet Encyclopedia"?

Sebastian G. wrote:
> Volker Birk wrote:
> > Todd H. wrote:
> >> GET and HEAD commands sent to a web server should do nothing but read
> >> some stuff. They shouldn't change anything.
> > Oh yes, they can. They can change some state in the web server, why not?
> Read the RFC: They shouldn't, and if you don't follow this, you run into a
> big load of problems like inconsistencies on load errors or Cross Site
> Request Forgery attacks.

Do you want to claim, that web applications, which are using GET
requests, are impossible to implement?

You're claiming here, that eBay don't exist BTW.

Yours,
VB.
--
"Es muss darauf geachtet werden, dass das Grundgesetz nicht mit Methoden
geschützt wird, die seinem Ziel und seinem Geist zuwider sind."

Gustav Heinemann, "Freimütige Kritik und demokratischer Rechtsstaat"

Re: Can anyone interpret this paragraph from "Connected: An InternetEncyclopedia"?

Volker Birk wrote:

> Sebastian G. wrote:
>> Volker Birk wrote:
>>> Todd H. wrote:
>>>> GET and HEAD commands sent to a web server should do nothing but read
>>>> some stuff. They shouldn't change anything.
>>> Oh yes, they can. They can change some state in the web server, why not?
>> Read the RFC: They shouldn't, and if you don't follow this, you run into a
>> big load of problems like inconsistencies on load errors or Cross Site
>> Request Forgery attacks.
>
> Do you want to claim, that web applications, which are using GET
> requests, are impossible to implement?


No. I claim they're impossible to implement correctly wrt. to how the
webbrowser as a client is modeled.

> You're claiming here, that eBay don't exist BTW.

No, I only claim that eBay is broken. Which it is, obviously.

Now will you please read my statement again? What part of "shouldn't" didn't
you understand?

Re: Can anyone interpret this paragraph from "Connected: An Internet Encyclopedia"?

Sebastian G. wrote:
> Now will you please read my statement again? What part of "shouldn't" didn't
> you understand?

I really don't understand how dumb a "discussion" can become.

VB.
--
"Es muss darauf geachtet werden, dass das Grundgesetz nicht mit Methoden
geschützt wird, die seinem Ziel und seinem Geist zuwider sind."

Gustav Heinemann, "Freimütige Kritik und demokratischer Rechtsstaat"

Re: Can anyone interpret this paragraph from "Connected: An Internet Encyclopedia"?

On 2007-07-02, Sebastian G. wrote:
> Volker Birk wrote:
>
>> Todd H. wrote:
>>> GET and HEAD commands sent to a web server should do nothing but read
>>> some stuff. They shouldn't change anything.
>>
>> Oh yes, they can. They can change some state in the web server, why not?
>
> Read the RFC: They shouldn't, and if you don't follow this, you run into a
> big load of problems like inconsistencies on load errors or Cross Site
> Request Forgery attacks.

Using POST instead of GET won't necessarily stop cross-site request
forgeries, though, if an attacker can get his victim to execute a
little bit of JavaScript...

(Not that I disagree with you in general; allowing GET commands to
change an application's state is definitely bad joojoo.)

--
Mark Shroyer
http://markshroyer.com/

Re: Can anyone interpret this paragraph from "Connected: An InternetEncyclopedia"?

Mark Shroyer wrote:


> Using POST instead of GET won't necessarily stop cross-site request
> forgeries, though, if an attacker can get his victim to execute a
> little bit of JavaScript...


Hm? Even form.submit() causes a warning if the form submission method is POST.

Re: Can anyone interpret this paragraph from "Connected: An InternetEncyclopedia"?

Volker Birk wrote:

> Sebastian G. wrote:
>> Now will you please read my statement again? What part of "shouldn't" didn't
>> you understand?
>
> I really don't understand how dumb a "discussion" can become.

Oh, that's quite easy: Just take a fool who doesn't understand that GET
requests are expected to not change the application state, but then doing so
leads to a inconsistency between server and client.

Re: Can anyone interpret this paragraph from "Connected: An Internet Encyclopedia"?

On 2007-07-07, Sebastian G. wrote:
> Mark Shroyer wrote:
>
>> Using POST instead of GET won't necessarily stop cross-site request
>> forgeries, though, if an attacker can get his victim to execute a
>> little bit of JavaScript...
>
> Hm? Even form.submit() causes a warning if the form submission method is POST.

Generally speaking, that isn't true. Which browser are you using?

--
Mark Shroyer
http://markshroyer.com/

Re: Can anyone interpret this paragraph from "Connected: An InternetEncyclopedia"?

Mark Shroyer wrote:

> On 2007-07-07, Sebastian G. wrote:
>> Mark Shroyer wrote:
>>
>>> Using POST instead of GET won't necessarily stop cross-site request
>>> forgeries, though, if an attacker can get his victim to execute a
>>> little bit of JavaScript...
>> Hm? Even form.submit() causes a warning if the form submission method is POST.
>
> Generally speaking, that isn't true. Which browser are you using?

Mozilla Seamonkey 1.1.2. Which browser don't have such a general check for POST?

Re: Can anyone interpret this paragraph from "Connected: An Internet Encyclopedia"?

On 2007-07-07, Sebastian G. wrote:
> Mark Shroyer wrote:
>
>> On 2007-07-07, Sebastian G. wrote:
>>> Mark Shroyer wrote:
>>>
>>>> Using POST instead of GET won't necessarily stop cross-site
>>>> request forgeries, though, if an attacker can get his victim to
>>>> execute a little bit of JavaScript...
>>> Hm? Even form.submit() causes a warning if the form submission
>>> method is POST.
>>
>> Generally speaking, that isn't true. Which browser are you using?
>
> Mozilla Seamonkey 1.1.2. Which browser don't have such a general
> check for POST?

None of the latest versions of Firefox, Safari, and IE 7 (the latter
operating with the default security settings for the Internet Zone)
will prevent scripts from submitting a form by POST or require user
authorization to do so. For example:

#v+

JavaScript form submission example

Test whether the web browser gives a warning on a JavaScript form
submission by POST.