Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

"Hardening" a web forum app

by Cody Fendant (Friar)
on Apr 07, 2011 at 02:05 UTC ( #897917=perlquestion: print w/replies, xml ) Need Help??
Cody Fendant has asked for the wisdom of the Perl Monks concerning the following question:

I've written a simple forum, using DBI, HTML::Template and CGI::Session.

It wasn't intended to be a professional product, it was just for a small group of people who can all be trusted. But what if it goes live to a wider audience?

What would you do to harden that application against people who might URL-hack or otherwise try to exploit weaknesses?

To give one example: if I've made a post, I can edit it. The Edit Post URL is And that's fine because I wrote post 123. What if I change the URL to 122? Can I edit someone else's post? What if I use that URL to edit my own post 123 then change the hidden form field value to 122? Can I save post 123 into post 122?

Now, I'm quoting those because I've thought of them. And I can trivially code for them. If the user id != the user id who made the post, etc. But as they say, everyone is clever enough to invent a code that they can't break themselves...

(I should say by the way that my DBI database calls all use placeholders, no interpolation of variables, so I don't think I'm vulnerable to the Bobby Tables kind of problem. But tell me if that's not enough.)

What principles or procedures should I follow to identify and prevent that kind of exploit?

Replies are listed 'Best First'.
Re: "Hardening" a web forum app
by ww (Archbishop) on Apr 07, 2011 at 03:16 UTC

    Addressing "principles" first (but directing this response to your broad question on exploitation, rather than to the specific examples of potential problems): the simplest may be to use existing, well-tested OS forum s/w. Rolling your own with even a glimmer of a possibility of opening its use to other than those who "can all be trusted" is either:

    1. An example of the triumph of hope over experience
    2. A long-term committment to bug-erradication; hole-plugging; and user-hand-holding

    Nonetheless, ++ for thinking about it....

    Now, some possibly relevant procedures:

    • -T
    • POST; not GET
    • 2-part login uname & pass) required and retained throughout session (you've already addressed this?)
    • uname (+reference to hashed_pass) included (hidden) when a node is created.

    And far beyond the trivia above, lots of heavy reading about vulnerabilties and how to minimize them.

Re: "Hardening" a web forum app
by moritz (Cardinal) on Apr 07, 2011 at 06:45 UTC
[OT] URL structure (Was: "Hardening" a web forum app)
by MidLifeXis (Monsignor) on Apr 07, 2011 at 13:41 UTC

    This is off topic from the original post, but I have a slight (hopefully constructive) criticism about your URL structure. Is the editor or the post the resource? In my mind, the post is the resource you are making available, and the editor is an action that you want to do to that resource.

    May I suggest that perhaps the URL should be reversed: The article ID is the identifier for everything else that happens to that resource.

    Whether or not you adhere to REST or some other method of organizing your resources, I posit that having the ID first will make it easier to manage your application in the future.


Re: "Hardening" a web forum app
by sundialsvc4 (Abbot) on Apr 07, 2011 at 15:51 UTC

    I have built several applications in which the URLs that are generated for a page consist of a URL consisting simply of GUID=xxxx-xxx-xxxx.....   As the page links are generated within the application, they are stored in a hash by GUID – generated on-the-spot for one-time use – and that hash is saved in the session information.   This creates an impenetrable href, but also one that cannot be meaningfully “farmed,” either by Google or by the competition.   (The Google-unfriendliness can be viewed as either a good thing, or a bad thing, as the business case may be.)

    A hybrid technique might use a more “Google friendly” URL structure, e.g. like the one commonly used by WordPress or Moveable Type based forums, but with the addition of such a code.   If the code is omitted or is not valid for any reason, the software might present a “sanitized” version of the page.   If you generate an XML sitemap file, it would omit all codes, so that Google would not generate any links involving them.

    This technique, while not perfect, does reduce the number of times you must do page-access validation.   As long as the inbound request has a valid code, and the IP-address has not changed, and the page is not highly sensitive, you can get away with just the code-check.   (Naturally, you will use “hardened” session cookies, courtesy of many CPAN modules that will generate them for you, and you will verify that the connection uses HTTPS.)

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://897917]
Approved by ww
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (11)
As of 2018-06-22 16:15 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (124 votes). Check out past polls.