I'm doing some research on Perl CGI vulnerabilities. Most Perl CGI's seems
to have some weaknesses, and it's just a matter of manipulating them
properly to make a proper exploit.

By far, the biggest problem is weak (or even no) filtering of form
fields. It only takes one line (s/\W+//g), yet this is rarely done properly.

Other problems include:

- Not filtering cookies.
        Very often, CGI's filter fields, but don't realize that cookies must also
be filtered for evil characters.
- Trusting the browser
        Not only can hidden fields be arbitrarily changed by anyone who at the
least knows HTML, but so can cookies, HTTP_REFERER fields, and anything else.
        (Recently, after I informed the maker of a very popular CGI about a
vulnerability in it, I was told "That's impossible!!! We check the
HTTP_REFERER field!" Netcat, anyone? <I guess they don't teach that in CS
school. . . > )

The following are indirect problems:

- Error messages too verbose
        While not a direct vulnerability, these often provide a lot of information
on server structure, as well as filtering of evil characters. There is
really no point in telling the user all about your server internals, so
send these messages to the error log, not the stdout.
- Cookie/hidden field predictability
        Again, this is not a direct vulnerability, but may allow for hijacking of
other users accounts and the like. It can become a vulnerability if admin
access can be gained this way.
- Allowing creation of (semi-)arbitrary files on server
        Many CGI's can be used by attackers to create files on the server which
they need in order to take advantage of other holes. Be restrictive in the
type of files that your CGI creates - the more specific the format, the
harder it will be for an attacker to make use of.

My question for the list is as follows: What did I miss? Most of the real
damage in my list can be eliminated with just a few lines of extra code -
the major problem being that most CGI programmers don't know/care. But I'm
sure there are some other problems, harder to exploit but harder for the
programmer to avoid as well, that are out there. Anyone . . . ?

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