Re: [Erlyaws-list] form field names as atoms?

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

http://sourceforge.net/mailarchive/message.php?msg_id=28987006

> Can you provide a small test case?
> 
> --steve

I would be happy to provide a small test case if we agree there is the potential for a problem here.  First, lets try to agree (or not).

Referencing pages 16-17 in yaws.pdf:

--------------------------------------------
In order to POST data a form is required. Say that we have a page called form.yaws that contain the following code:

<html>
<form action="/post_form.yaws"
method="post"
<p> A Input field
<input name="xyz" type="text">
<input type="submit">
</form>
</html>

This will produce a page with a simple input field and a submit button. If we enter something—say, “Hello there”—in the input field and click the submit button the client will request the page indicated in the “action” attribute, namely post_form.yaws. If that YAWS page has the following code:

out(A) ->
    L = yaws_api:parse_post(A),
    {html, f("~p", [L])}.

The user will see the output

[{xyz, "Hello there"}]
--------------------------------------------

My question:  Rather than using the html (above), couldn't someone write a script to post to post_form.yaws (above) over and over again, using randomly-generated field names?  If so, then wouldn't out/1 create more new atoms each time it called parse_post/1?  If so, is that a problem or not?

I can envision several potential retorts:

Retort 1:  post_form.yaws out/1 runs in it's own erlang process which is created and destroyed each time it is hit from the web.  So yes, while it creates atoms each time, those atoms are destroyed when post_form.yaws and out/1 finish because those atoms are in a self-contained process.  Nothing to worry about here.

My answer 1:  Ah, got it.  Didn't know so much about yaws innards - that's why I came here.

Retort 2:  Hmmm, it could be that erlang and/or yaws allocates these atoms system-wide, not merely for a particular process which is created and destroyed.  Which means... yes, there could be a potential exploit here.  Can you write up that small test case?

My answer 2:  Ah... sure.  I'll start on that small test case when I have time.

> I wouldn't worry about such an attack because
> it needs posting a lot of data for your system
> to run out of the memory. Nevertheless, if you
> feel safer, you can filter out the POST methods
> with too high memory consumption (after all,
> it's Erlang there).
>
> CGS

If this kind of attack is possible, I might have to worry about it.  The web site I am building will be deployed in a particular market where all other major competitors have been attacked in every way possible.  Attacks have succeeded against their web sites, even to the point of having hundreds of thousands of dollars lost (literally).  So, I'm interested if there is a potential exploit here, because if this project ever goes "live," it will be attacked guaranteed.

Can you be more specific about your idea of filtering out post methods with too high memory consumption?

Thanks.