Usually that kind of attack can be of few types:
1. speculating the number of characters per field;
2. speculating escape characters within the field;
3. intentional crash of the page to see the code;
4. flooding the page with requests.

As you can see, the only type of attack which may lead in memory starvation is the fourth from the list. To avoid that, just return an error message as soon as the memory load reaches a certain level (set by you), so, the memory is freed as soon as the POST request is registered. For more info, see


or the next in the list (memory/1) which can provide with a test of memory consumption by a certain element.

For protecting yourself against the intentional crash of a given page, just put your sensitive data in a module (a .beam file) in the YAWS ebin path (see yaws.conf from /etc/yaws/ or any alternative path) and call it from POST answering page. In such way, even if the page is crashed, no sensitive data is revealed. Nevertheless, do not forget to test if the field of interest exists in the POST action before trying to access its value.

Escapes characters can be avoided by filtering out any undesired characters. For example, let's consider a string (list in Erlang)

A = "I \w@n\t 2 h@ck u1"

which comes from a POST field. By simply checking:

T = string:tokens(A,"ABCDEFGHIJKLMNOPQRSTUVWXZabcdefeghijklmnopqrstuvwxz0123456789");
case length(T) of
   0 -> {success, "Test passed"};
   _ELSE -> {error, "Invalid chars: "++T}

your function will return an error and, further on, you just discard the input.

As for the attack coming from field length speculation, there are two options:
a) memory consumption of the list (see memory/1);
b) length of the string (see length/1) can work fine as well because Erlang does not have a limit for the length of the list.

In this way, you protect yourself against the most "popular" attacks. If you know of more ways to start an attack which are not stopped by these methods, please, let me know.


On Fri, Mar 16, 2012 at 10:33 AM, xxx xxx <nowhereface@live.com> wrote:

> 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:

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

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).

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?


This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
Erlyaws-list mailing list