comment on

Unless the middle-tier process is using identd or some other mechanism of testing the privileges on the 'trusted' web server, *any* user from the web server could connect to this off-server process.

Typically there's a firewall between the web server and the middle tier. And speaking an application-specific protocol across this boundary does improve security. The hacker is constrained to used the application-specific protocol, and is blocked from using raw SQL, thus limiting the amount of probing they can do.

Eventually the only practical solution comes down to controlling access to the web account, and making the CGI read-only to the web account.

And if you lose the box to some other exploit, the hacker gets a valid database username and login. Even if the pair that the CGI uses is for an INSERT-only account, if the database is on the same box, it's toast.

In reply to Re: Re: Re: Secure ways to use DBI? by dws
in thread Secure ways to use DBI? by outcast

Are you posting in the right place? Check out Where do I post X? to know for sure.
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
Want more info? How to link or How to display code and escape characters are good places to start.


We don't bite newbies here... much
	PerlMonks