5

I have a line where I grab a database row with .get(field = ID). A normal user would always send an ID that exists in the database, but a hacker might not, and it would throw a DoesNotExist exception. Is it important to explicitly catch it or should I just leave the exception uncaught in that case? Either way, the hacker would not see any message so there is not any security risk either way.

I'm also wondering whether I should log this exception failing. Would be interested in hearing what you guys do as a general rule of thumb, and your justification for what you log/catch vs. what you let throw an uncaught exception.

Ben G
  • 26,091
  • 34
  • 103
  • 170

1 Answers1

2

The important part is in which context you are using this field. If you access the page through /profile/[ID] I would display a User not found page. If you do something like that

ID = context["user"].id
Object.get(field = ID)

I wouldn't try to catch the error seperately.

All in all I save every error which can not be caused through normal user behaviour. Then I can take a look into my error log and can directly see where my site raises failures or whether hackers tried to find a security hole.

Afterwards I fix this undefined behaviour so that the error log is as empty as possible.

blacklwhite
  • 1,888
  • 1
  • 12
  • 17
  • 1
    I agree. It depends on the content. If this query exists in your view which is directly connected to a users navigation or input, then you should handle a bad value and return a response. But if the query is at the model layer and the user has no direct access to it then you would not have an issue. Bottom line is filter and handle all user input. That includes GET and POST parameters – jdi Feb 02 '12 at 00:26
  • The context was a modal/ajax pop up. Based on what you two have said, I decided to catch the `DoesNotExist` exception in this case, and return an appropriate error message when a user tries to pass the modal dialogue an ID that isn't in the database. – Ben G Feb 02 '12 at 00:46