I see Oracle really have a handle on SQL Injection
-
-
The blacklist of characters sure look suspiciously like a sql injection AND HTML/JavaScript injection prevention list, but it makes no sense... why would they ever print your password into the webpage??? So now I wonder if the passwords are not only sql-injectable, but also stored in plain text for being able to print back out as well.
-
it is, from what I can tell, client side verification, each field on that page verifies the input as you complete the field, so it's to prevent you sending a SQL injection inside the password field when you submit the form.
-
I think there's a problem with part of that dialog:
Shouldn't that be
(><)
?
-
Eh, I'm tempted to say it should be
(%)
For a bit of a Picasso effect
-
-
More like
(><);;;;;;;
You can never be too careful....
Also, when I see client-side verification on things like that, it just BEGS me to submit manually bypassing the client-side verification just to see if they skipped implementing the server-side verification.
-
-
Not like you.
-
Yep, same. I'd love to catch Oracle out on something like that.
-
Did you try it? I can't be bothered.
-
It's not actually just JS validation. It's a callback to the server side page that validates the password, which is submitted by the input's onchange.
It's possible that they then end up skipping the re-validation when you actually submit the page, but that would take me a little more work and I don't have time at the moment.
-
a callback to the server side page that validates the password, which is submitted by the input's onchange.
