CODEWITHSUNDEEP
phphtmlsecurityxss
Senior Gamer
Senior Gamer

Reputation: 45

SQL preventation of XSS

Hey guys so Ive got a question, is there a something I could use when inserting data into the SQL to prevent XSS? Instead of when reading it.

For example I have quite bit of outputs from my sql that are user generated, is it possible to just make that safe on Entering SQL or do I have to make it safe when it leaves SQL?

TL:DR can I use something like htmlspecialchars when inserting data into SQL to prevent XSS, will that be any sort of good protection?

Upvotes: 0

Views: 191

Answers (2)

Gabor Lengyel
Gabor Lengyel

Reputation: 15599

I think several things are mixed up in the question.

Preventing XSS with input validation

In general you can't prevent XSS with input validation, except very special cases when you can validate input for something verz strict like numbers only.

Consider this html page (let's imagine <?= is used to insert data into your html in your server-side language because you hinted at PHP, could of course differ by language used):

<script>
    var myVar = <?= var1 ?>;
</script>

In this case, var1 on the server doesn't need to have any special character, only letters are enough to inject javascript. Whether that can be useful for an attacker depends on several things, but technically, this would be vulnerable to XSS with almost any input validation. Of course such assignment may not currently be in your Javascript, but how will you ensure that there never will be?

Another example is obviously DOM XSS, where input does not ever get to the server, but that's a different story.

Preventing XSS is an output encoding thing. Input validation may help in some cases, but will not provide sufficient protection in most cases.

Storing encoded values

It is generally not a good idea to store values html-encoded in your database. On the one hand, it makes searching, ordering, any kind of processing much more cumbersome. On the other hand, it violates single responsibility and separation of concerns. Encoding is a view-level thing, your backend database has nothing to do with how you will want to present that data. It's even more emphasized when you consider different encodings. HTML encoding is only ok if you want to write the data into an HTML context. If it's javascript (in a script tag, or in an on* attribute like onclick, or several other places), html encoding is not sufficient, let alone where you have more special outputs. Your database doesn't need to know, where the data will be used, it's an output thing, and as such, it should be handled by views.

Upvotes: 2

Stormhashe
Stormhashe

Reputation: 714

You should test the input for whitelist characters using a regex to only accept like [a-Z][0-9] for example. You'll have a big headache if you try the other way around, using a blacklist, because there are gigantic ways of exploiting input and catching them all is a big problem

Also, be aware of SqlInjections. You should use SqlMap on linux to test if your website is vulnerable

Upvotes: -1

Related Questions