undefined | Better HN

0 pointshueving10y ago0 comments

Dependent on what comes out of the DB, not what goes in.

0 comments

6 comments · 1 top-level

zeta013410y ago· 5 in thread

That still counts as a vulnerability, even if it's not exploitable without also being able to write the correct state into the database. Databases almost always contain user-generated data. I don't trust the data contained therein any more than I trust the user. Validate it every time.

huevingOP10y ago

Yes, I wasn't contradicting that. I was explaining what the issue was.

themihai10y ago

That sounds a bit too much. The data from db is supposed to be already validated. Do you validate the input received from the validation function as well?(⸮)

ifoundthetao10y ago

It's a second stage SQL injection, and it's very serious.

Here's a contrived example:

At the user creation page the malicious user wants to get admin access.

They have their username be: admin' --

They do this because they are betting on a user named 'admin'.

Their password is: alwaysSanitizeInputs

So, a user is created named "admin' --".

Now, they go in to update their password.

The DB nicely pulls out their username, "admin' --", and it says:

  UPDATE users SET password = SHA1('newPassword') WHERE username = 'admin' -- AND password = SHA1('alwaysSanitizeInputs');

So what happens? Well, the user "admin" now has a different password, and the Malicious user knows what it is. That's why you still need to sanitize.

1 more reply

zeta013410y ago

I'm not saying you need to fully validate the database, but at least making sure the row you're about to read can actually fit in the buffer you just allocated would be a good practice, even if the input validation shouldn't normally allow it.

If the database could theoretically hold it according to its schema, the program should be prepared for the largest row size that is still technically legal. (Where "prepared" may simply mean that it throws a "This should never happen" error and aborts the request.)

huevingOP10y ago

You don't have to fully validate it, just don't fail so spectacularily that it corrupts the heap or crashes the whole program.

Ideally a corrupt record only breaks the requests that read that record with an HTTP 500 or something similar.

j / k navigate · click thread line to collapse

0 comments

6 comments · 1 top-level

zeta013410y ago· 5 in thread

huevingOP10y ago

Yes, I wasn't contradicting that. I was explaining what the issue was.

themihai10y ago

That sounds a bit too much. The data from db is supposed to be already validated. Do you validate the input received from the validation function as well?(⸮)

ifoundthetao10y ago

It's a second stage SQL injection, and it's very serious.

Here's a contrived example:

At the user creation page the malicious user wants to get admin access.

They have their username be: admin' --

They do this because they are betting on a user named 'admin'.

Their password is: alwaysSanitizeInputs

So, a user is created named "admin' --".

Now, they go in to update their password.

The DB nicely pulls out their username, "admin' --", and it says:

  UPDATE users SET password = SHA1('newPassword') WHERE username = 'admin' -- AND password = SHA1('alwaysSanitizeInputs');

So what happens? Well, the user "admin" now has a different password, and the Malicious user knows what it is. That's why you still need to sanitize.

1 more reply

zeta013410y ago

huevingOP10y ago

You don't have to fully validate it, just don't fail so spectacularily that it corrupts the heap or crashes the whole program.

Ideally a corrupt record only breaks the requests that read that record with an HTTP 500 or something similar.

j / k navigate · click thread line to collapse