.--- On Mon, 13 Mar 2006, Randal L. Schwartz wrote: | So, sometimes, the best I can do is say "pull your arm away from that hot | stove, please", and hope that someone else can explain the temperature at | which flesh burns, etc. `---
I'll happily back you up on this arrangement. Here's a concrete example for all the folks who asked for it: Say we're building a web site which offers services which requires a customers to log in. (The mechanics of the log in process are secondary to this example because the attacker will use the authentication mechanism as it was intended; he subverts the system in another way.) The web site has the things you expect of such a website. It has a place you can sign up. It's got a form to change your account details. It even has a handy account rescue form, so that if you lose your login or password, you can at least log in and get control of your account. Let's look at an attack on the form that changes account details. The attacker notes that this form allows a customer to change their email address. So he copies this form onto his own system and changes the form action to point toward our POST URL, and starts adding params. His goal is to guess the names of existing variables in order to change their value. First he adds an "account_id" param to the form: <form name="change-account-details" action="http://www.victim.com/form/path";> Account ID: <input type="text" name="account_id" /><br /> First Name: <input type="text" name="first_name" /><br /> Last Name: <input type="text" name="last_name" /><br /> Email: <input type="text" name="email" /><br /> </form> He now has a convenient place to enter an account_id. Then, he fills in the form. He makes up a first name and last name, and fills in a value for the account ID. He starts with "1" since low-numbered accounts might have special privileges or reveal other details once compromised. For the email, he uses his own email. Finally, when he's done, he posts. Our document takes over. The first thing it does is authenticate the user -- after all, we don't want someone changing account details unless they're really logged in. The account ID gets stored in a variable called: $account_id. Next, we deal with the form. To do this, we grovels through %ARGS, because at some point we generalized form handling, but didn't want to require the caller to pass a list of args. "Why not get them automatically?" we thought. You can be sure that we'll soon find out. As the loop screams through the params, it sets variables with the names of the parameters with the values from the form, one after the other. One of these is account_id. Such a variable already existed, of course; we stored the account ID here in the auth mechanism. Now $account_id is overwritten with the value from the form. This is the first half of the attack. Meanwhile, the rest of the values get changed too, including the email address. That's the second part of the attack. The attacker has now set his own email address for this account. He starts receiving mails that should have gone to the account holder. They say things like: "Your account has new activity, niceperson1066!" But that's not the worst of it. He goes to the account rescue page and types in the email address or the account name. He receives, in turn, a URI that allows him to temporarily log as niceperson1066. The account is now fully compromised. This example may be better or worse than others, but I tried to make an example based on a typical site structure. Under the hood, our trust of %ARGS and our use of the symbol table for storage worked in concert to provide an attack vector. Either technique on its own yields pitfalls which provide such targets -- some fairly obvious and some not -- but together, they were fatal in short order. I provide this example not only to demolish techniques that'll run you into trouble, but to dedicate an area on which to build something better. I don't want to leave you without a strong solution. In my next article, I'll show you how to build a self-posting form that's just as self-contained as you'd like it to be. It'll make your URIs neat as a tack, it's enjoyable to work with, and it takes into account what we've learned here. Mason's done worlds of good for me. It's clean and elegant. I delight in using it. I wish it were even more popular, and to that end, I hope to give back to the community by providing document- and component-level building blocks that you can use to make a secure, neat site. My techniques won't be universally applicable, and of course they have limitations of their own. But I've found some ways of doing things that bring me joy, and I'll freely share the techniques (and the joy) if they're useful to anyone. Thanks for reading. Best regards, -- Patrick -- .------ Patrick M. Jordan ------. Random unused band name: | Systems/Network Administrator | DJ Parsing Error `----- Antistatic Matrix -------' ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Mason-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mason-users
