Very interesting variant of protection against SQL injection and XSS.
One very respected Mr. Den Kaminsky (Dan Kaminsky - known for finding a fundamental vulnerability in the DNS) offered a very interesting universal protection technique against SQL injection and XSS .
The method is very simple and from the fact of genius.
The essence of the technique is reduced to the substitution in SQL queries of all the data in the base64 representation, and thus it makes no sense to use any parsers / analyzers used in the SQL query data (placeholders, etc.)
All this can be roughly described as a type string:
"SELECT * from mytable where textfield = base64_decode ('Q29vbEhhY2tlcnM =')"
where base64_decode is the decoding function from base64 that is allocated to a specific database.
')
There are no special characters in base64 and therefore no threat to our request from the data entered into it. There is no need to somehow shield or change the input data. It is enough to encode them in base64 and pass in the request.
The technique is also applicable on the client side - if you need to remove the data in quotes, for example, in an event handler or in js. Base64 decoding can be done right in js when you need to get the original data.
From my point of view, the method is brilliant. There are two drawbacks (in my opinion) - an increase in memory for variables stored in this way will be 30% (base-64 coding feature), as well as an increase in server load due to the need to encode input parameters (I think that can be neglected), and server load DB due to the need to be extended (but I think this will not be neglected).
However, to be precise, it is necessary to do experiments, and maybe there are knowledgeable people among users who are ready to share their opinion on this matter?
Related Links:
Dan Kaminsky
base64
Dan Kaminsky about his method
The method is very simple and from the fact of genius.
The essence of the technique is reduced to the substitution in SQL queries of all the data in the base64 representation, and thus it makes no sense to use any parsers / analyzers used in the SQL query data (placeholders, etc.)
All this can be roughly described as a type string:
"SELECT * from mytable where textfield = base64_decode ('Q29vbEhhY2tlcnM =')"
where base64_decode is the decoding function from base64 that is allocated to a specific database.
')
There are no special characters in base64 and therefore no threat to our request from the data entered into it. There is no need to somehow shield or change the input data. It is enough to encode them in base64 and pass in the request.
The technique is also applicable on the client side - if you need to remove the data in quotes, for example, in an event handler or in js. Base64 decoding can be done right in js when you need to get the original data.
From my point of view, the method is brilliant. There are two drawbacks (in my opinion) - an increase in memory for variables stored in this way will be 30% (base-64 coding feature), as well as an increase in server load due to the need to encode input parameters (I think that can be neglected), and server load DB due to the need to be extended (but I think this will not be neglected).
However, to be precise, it is necessary to do experiments, and maybe there are knowledgeable people among users who are ready to share their opinion on this matter?
Related Links:
Dan Kaminsky
base64
Dan Kaminsky about his method
Source: https://habr.com/ru/post/100552/
All Articles