Hacker was able to send virus via text field maxlength="50" - HOW?

I have never in my life seen anything like this. One of my websites
was hacked tonight by a hacker who was able to send a DoS-related viral
packet of data through a text field on my site that has maxlength="50"
(the data packet itself was about 1024 bytes in length, and several
packets were sent).

Can anyone tell me how on earth that is possible? I can't even
duplicate that or come close to it, and yet someone has not only done
it but done it repeatedly, and how do I stop them?

Thanx
Phil

On Sat, 16 Sep 2005, phillip.s.powell (AT) gmail (DOT) com wrote:

I have never in my life seen anything like this. One of my websites
was hacked tonight by a hacker who was able to send a DoS-related viral
packet of data through a text field on my site that has maxlength="50"

Can we presume that this "text field" is part of a form, and that you
have some kind of server-side process associated with it? I'm going
to have to make that assumption in order to make any kind of progress.

[..]

Can anyone tell me how on earth that is possible?

Insufficient detail, but if you need to ask that question, you're too
dangerous to run the associated server-side process. My counsel would
be to take it down until you understand web security better.

Lincoln Stein has a rather good tutorial on web security: it should
make a good starting point.

One can never, ever, rely on limits set on an HTML page. Protection
*has* to be built into the server-side process, which must deal with
*anything*, just anything, that is thrown at it, without reference to
what you code into your HTML.

phillip.s.powell (AT) gmail (DOT) com wrote:

I have never in my life seen anything like this. One of my websites
was hacked tonight by a hacker who was able to send a DoS-related viral
packet of data through a text field on my site that has maxlength="50"
- -
Can anyone tell me how on earth that is possible?

Read Alan's reply carefully. It's a bit harsh (almost as harsh as I
intended to write...), but you may need that.

To demonstrate how it is not just possible but extremely easy, copy the
page (or any form that has a maxlength attribute in a <textarea>
element) onto your local disk, open the page in any editor, add a <base
href="..."> element where "..." is the absolute address of the original
page (this might not be needed), and edit the <textarea> element by
removing the maxlength attribute or by changing it to
maxlength="42424242". Then open the page in a browser and submit as much
data as you like. (Browsers may actually impose some limitations on the
size of textarea data or on form data as a whole, but if they do, the
limitations allow much larger bulks of data than 50 characters.)

Of course, people who want to make DoS attacks know how to do such
things more efficiently, e.g. just look at the action attribute you
have, resolve it to an absolute address, and use a program of their own
to send anything they like to that address, at an unreasonable rate.
Much of this can be automated, so that they can attack a million servers
at a time.

phillip.s.powell (AT) gmail (DOT) com wrote:

I have never in my life seen anything like this. One of
my websites was hacked tonight by a hacker who was able to
send a DoS-related viral packet of data through a text
field on my site that has maxlength="50" (the data packet
itself was about 1024 bytes in length, and several packets
were sent).

Can anyone tell me how on earth that is possible?

It is trivial. It starts with something as simple as typing:-

javascript:void (document.formName.fieldName.maxLength = 2147483647);

Into the location/address bar of a script enabled web browser and
hitting return (re-setting the maxLength of any field you like (the
value used is the default, and so theoretically the maximum, on Windows
IE)). And then it goes on through many intermediate possibilities until
you get to the dedicated custom HTTP request sending software described
nearby.

Effort put into setting HTML attributes on form controls, and providing
client-side validation, should be thought of as effort towards improving
the user's experience while interacting with a page/form and in no way
related to security or input data validity.

<snip>

... , and how do I stop them?

You cannot control the requests sent to a server, you can only control
how that server will react to them.

Richard.

On Saturday 17 September 2005 06:39,
phillip.s.powell (AT) gmail (DOT) co...mail (DOT) com) wrote in message
<1126935567.535585.322620 (AT) g43g2000cwa (DOT) googlegroups.com>

I have never in my life seen anything like this. One of my websites
was hacked tonight by a hacker who was able to send a DoS-related viral
packet of data through a text field on my site that has maxlength="50"
(the data packet itself was about 1024 bytes in length, and several
packets were sent).

Can anyone tell me how on earth that is possible? I can't even
duplicate that or come close to it, and yet someone has not only done
it but done it repeatedly, and how do I stop them?

In Opera8.02 (and some earlier versions) there is a very nice feature where
you can reload a page from the cache.

That means I can view the source code for your page in a text editor, make
any changes I want, save the page back to the cache, refresh the page from
the cache then send whatever information I want to your server.

Changing or removing maxlength="50" would be the work of a moment and you
can't stop it from happening. All you can do it cope with the results.

Jukka K. Korpela wrote:

phillip.s.powell (AT) gmail (DOT) com wrote:

I have never in my life seen anything like this. One of my websites
was hacked tonight by a hacker who was able to send a DoS-related viral
packet of data through a text field on my site that has maxlength="50"

- -

Can anyone tell me how on earth that is possible?


Read Alan's reply carefully. It's a bit harsh (almost as harsh as I
intended to write...), but you may need that.

To demonstrate how it is not just possible but extremely easy, copy the
page (or any form that has a maxlength attribute in a <textarea
element) onto your local disk, open the page in any editor, add a <base
href="..."> element where "..." is the absolute address of the original
page (this might not be needed), and edit the <textarea> element by
removing the maxlength attribute or by changing it to
maxlength="42424242". Then open the page in a browser and submit as much
data as you like. (Browsers may actually impose some limitations on the
size of textarea data or on form data as a whole, but if they do, the
limitations allow much larger bulks of data than 50 characters.)

Of course, people who want to make DoS attacks know how to do such
things more efficiently, e.g. just look at the action attribute you
have, resolve it to an absolute address, and use a program of their own
to send anything they like to that address, at an unreasonable rate.
Much of this can be automated, so that they can attack a million servers
at a time.

Just wondering: how much would the striptags function protect you from
attacks like this?

... hacked tonight by a hacker who was able to send a DoS-related viral
packet of data through a text field on my site that has maxlength="50"

Changing or removing maxlength="50" would be the work of a moment and you
can't stop it from happening. All you can do it cope with the results.

I'm one of those people that is still learning to use ASP as one method
of doing server side programming.

If I had a program that accepted parameters like this, would this be an
adequate method of coping?

size = Request.form("width")
if size="" then size=Request.QueryString("width")
if len(size)>50 then size="default"

Or should I search for a method of eliminating that variable from the
form or query string completely with the equivalent of form("width")=""
(I have no idea if that's even a valid code).

If I merely use these parameters in text mode, as names or numbers,
does this still mean that it can be used in some way that I don't
intend, as I assume that the success of such an attack depends on the
code on my page?

Just curious, and interested to learn more.

John

On Saturday 17 September 2005 20:55, John(GodLovesEveryone.org (AT) gmail (DOT) com)
wrote in message <1126986919.758857.317430 (AT) f14g2000cwb (DOT) googlegroups.com>

... hacked tonight by a hacker who was able to send a DoS-related viral
packet of data through a text field on my site that has maxlength="50"

Changing or removing maxlength="50" would be the work of a moment and you
can't stop it from happening. All you can do it cope with the results.

I'm one of those people that is still learning to use ASP as one method
of doing server side programming.

Same here.

If I had a program that accepted parameters like this, would this be an
adequate method of coping?

size = Request.form("width")
if size="" then size=Request.QueryString("width")
if len(size)>50 then size="default"

That's what I would have used but I suspect there is something much better
and harder to break.

Or should I search for a method of eliminating that variable from the
form or query string completely with the equivalent of form("width")=""
(I have no idea if that's even a valid code).

If I merely use these parameters in text mode, as names or numbers,
does this still mean that it can be used in some way that I don't
intend, as I assume that the success of such an attack depends on the
code on my page?

You'd need to filter out invalid characters. "Regular Expressions" can help
here but I can't as I haven't got that far yet. :-)

In article <1126986919.758857.317430 (AT) f14g2000cwb (DOT) googlegroups.com>,
"John" <GodLovesEveryone.org (AT) gmail (DOT) com> wrote:

... hacked tonight by a hacker who was able to send a DoS-related viral
packet of data through a text field on my site that has maxlength="50"

Changing or removing maxlength="50" would be the work of a moment and you
can't stop it from happening. All you can do it cope with the results.

I'm one of those people that is still learning to use ASP as one method
of doing server side programming.

If I had a program that accepted parameters like this, would this be an
adequate method of coping?

size = Request.form("width")
if size="" then size=Request.QueryString("width")
if len(size)>50 then size="default"

No: that's focusing on the wrong part of the problem. Chances are, the
value of the "width" attribute, while interesting, is not something the
server is particularly interested in getting from the form.

I.e., the server shouldn't be depending on the _form_ to tell it what
width input to expect. As others have mentioned, that value can be
easily hacked. The server should know on its own what width to expect.
Code it as a constant, read it from a config file, whatever: but don't
get it from the form.

Now that you know what the width _should_ be, then the only thing you
care about is whether the submitted value is within that width (take the
length of the string and compare it to width value that you've coded on
the server side). If the submitted value is too large, you can truncate
it to fit, or just reject the input altogether (ask the visitor to try
again). It's up to you. But that's the issue you need to worry about (or
one of them anyway): if the value fits in the width that the server
knows is correct, not whether it fits in the width that the form claims.

Another thing you need to worry about is what you're going to do with
that input. If at some point that input is going to be sent back as part
of a web page (e.g., a message-board posting that others will read
later), you need to make sure that it doesn't contain executable
JavaScript (which could be malicious), etc. The easiest thing to do is
not allow anything but simple html in the submission, or to transform
any markup to entities (e.g., "<" to "&lt;") so that when it is
re-emitted as part of another page, the browser handles it as plain
text, not html markup.

There is a name for this type of exploit, which unfortunately has
slipped my mind. Googling for "javascript injection" or "html form
exploit" might give you some leads though.

If I merely use these parameters in text mode, as names or numbers,
does this still mean that it can be used in some way that I don't
intend, as I assume that the success of such an attack depends on the
code on my page?

It all depends on how the input is going to be used. If anything -- a
browser, an operating system shell, a database engine -- is going to be
doing any sort of processing or execution of the input, then it's
potentially exploitable, and you need to actively guard against it.

--
Joel.

If I merely use these parameters in text mode, as names or numbers,
does this still mean that it can be used in some way that I don't
intend, as I assume that the success of such an attack depends on the
code on my page?

It all depends on how the input is going to be used. If anything -- a
browser, an operating system shell, a database engine -- is going to
be doing any sort of processing or execution of the input, then it's
potentially exploitable, and you need to actively guard against it.

In my case, I'm using the information as purely text or number
parameters that do NOT get used in the form submitted.

One parameter might be to determine the size of a puzzle, and is
expected to be a numeric value (and I've already set the program to
change any value less than 5 or greater than 100 to a value like 15 or
100).

The other parameter is expected to be a name, and I can easily add a
vbscript command to truncate any name longer than a particular maximum.
I basically use the letters of the name one letter at a time, and I
only process particular letters and reject non-complying letters, but I
process them one letter at a time and never use them together, though I
might want to repeat the name in the title bar.

So, if I never do anything with the text input other than truncate
anything longer than 30 characters (for example), strip out characters
that are not displayable by my rules, and include the remaining name in
the title tag and an H1 tag, am I fairly immune from these attacks?

(Thanks for such an interesting topic, whoever started this
discussion).

John