|
|
Posted by Michael Fesser on 01/16/07 20:36
..oO(Tim Roberts)
>Michael Fesser <netizen@gmx.de> wrote:
>>
>>It's also a security issue. Using plain links to change or delete
>>something on the server can become a problem or even a security risk.
>
>I don't think that's really what you meant to say.
It is.
>There is no difference
>in security between GET and POST. If there's something that is dangerous
>as a GET, then it's dangerous as a POST.
There's a difference. Just two examples:
1) Web crawlers can follow links, but they usually don't submit forms
(let aside spam bots). In conjunction with other problems and bugs on a
site the result can be very drastic, see
http://thedailywtf.com/Articles/Best_of_2006_0x3a__The_Spider_of_Doom.aspx
2) The default request method for pages and other resources like images
etc. is GET. This can be abused as well to fool the browser into sending
a malicious request itself, see
http://groups.google.com/group/comp.lang.php/msg/42c80631acf96223
There are good reasons why GET should not be used to change the server
state. That's what POST is for.
>>>Nope. That's not the problem. Another responder nailed it: you have to
>>>tell the <textarea> that you want the newlines by saying <textarea
>>>wrap="hard">.
>>
>>That's no HTML.
>
>Of course it is. What would you call it?
A proprietary NN (or MS) invention. It's not part of the HTML standard.
>>I've tested Opera, FF, IE and Lynx - all browsers send correct line
>>breaks from a textarea, regardless of the used method (GET or POST).
>
>Try entering this:
>
> This is a very long line that exceeds the width of the text area without
>having any hard carriage returns at all.
>
>With a plain <textarea>, you'll get no separators.
Exactly, because there are none. The OP's problem, as he described it,
was explicit line breaks ("user pressed 'return key'") not making it
into his script, which is somewhat different.
Micha
Navigation:
[Reply to this message]
|