OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Sverre H. Huseby (shhthathost.com)
Date: Sat Sep 22 2001 - 18:28:18 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    [Tony Welsh]

    | [...] the article covers how far sql can be subverted - something
    | which its quite easy to forget. [...]
    | http://www.securiteam.com/securitynews/5VP022K56K.html

    The article shows just a tip of the iceberg. Or something like that.
    If you are able to insert your own SQL, you may do almost anything.
    From gaining access without knowing the password, as they show in this
    article, via deleting and updating information, to extracting
    information using creative UNION SELECT statements.

    I do not fully agree in the solution outlined in the article. First
    of all, they mention using JavaScript for validating input.
    JavaScript runs on the client side, and "there's no such thing as
    client side security", to quote a nice book (Hack Proofing Your
    Network, if I remember correctly). They do mention that JavaScript
    may be bypassed, so why mention it at all?

    Second, they do output filtering on the input side (using
    htmlspecialchars). If you filter HTML before storing stuff in the
    database, you will run into problems when the data sometime in the
    future will be used for other things than HTML. You also risk running
    into problems like the following: Imagine a user entering the
    following to be stored in a database:

      \074script\076 ...

    with htmlspecialchars nothing happens to the input. If this string is
    stored in a database that uses backslash as an escape character, like
    for instance PostgreSQL does, the \074 and \076 will be mapped to <
    and > respectively. As HTML tag filtering was done on the input side,
    it will not be repeated on the output side, and bad guys may thus
    bypass the HTML washing mechanism.

    The sample in the article won't run into this problem, as they also
    use addslashes that escapes the escapes. But escaping the escapes is
    easily forgotten. In my opinion you should wash/validate input on the
    input side, and output on the output side. Mixing sides gives
    problems.

    Oh, well. I just got home from a big party, so I hope my gibberish
    makes sense. :)

    Sverre.

    -- 
    shhthathost.com			Try my Nerd Quiz at
    http://shh.thathost.com/		http://nerdquiz.thathost.com/