search

agnelvishal / Condense.press

GNU General Public License v3.0
12 stars 25 forks source link

SECURITY: fixed sql injection #18

Closed SteveEdson closed 5 years ago

SteveEdson commented 5 years ago

The post data could easily use SQL injection to alter the database statements. You should always escape input that could come from a user.

Also, it's never a good idea to store your database connection details in an open source user that anybody could connect to.

agnelvishal commented 5 years ago

But the user associated with the database credentials has only read access. Is it still necessary to escape input and hide database connection details?

SteveEdson commented 5 years ago

Yes, it should always be done, no exceptions.

For example, at a later date you add in more information to the database, possibly a table for users to login etc, the SQL query could be injected and this could be exposed. Also, if this was on a database server that held other databases, the query could potentially dump information from those databases too.

Brcrwilliams commented 5 years ago

TBH, I would recommend removing the password from the code as well, and storing it in either a file on the host that is outside of the web root, or as an environment variable. Allowing strangers to connect to your database is something that is very prone to abuse, even if your database user is select-only. At the very least, they can run performance-intensive queries and bring down your server or balloon your AWS charges.

agnelvishal commented 5 years ago

Fixed sql injection by escaping inputs