SQL Injection on asp - Check website for vulnerability

Started by amitkedia, Jul 20, 2022, 01:05 AM

Previous topic - Next topic

amitkediaTopic starter

Good day,

I work as a web specialist at one company, recently the management gave the task to check our site for threats from intruders.
The site does not represent any value, the content that is on the site is updated very rarely. However, management has its own vision on this matter.
I understand that it would be wiser to entrust this matter to professionals.

As a result, the task is as follows, check the site for vulnerability. Immediately remembered sql injections. Looking for articles about this topic.  In my case, the site is written in asp. And the examples that are described in the article do not work in my case.

At the end, I decided to turn to the forum and ask for advice.

Website content currently includes the following:

windows server / IIS 7.0 / Database: MySQL / Managed by: Myphpadmin / pages written in asp.net

Dear forum users, tell me something useful, and to which direction should we move.

Thanks.
  •  

Hitesh Patel

If injection goes into the server, then you can already find out what kind of server.
To approx. query to MySQL server SHOW VARIABLES. SHOW VARIABLES -> version.
But generally, in theory, yes, if you didn't find a hole, then you won't know what kind of database server engine it is.

It is necessary to select queries for injection with universal SQL keywords. But the important thing is to see the server's response, already by the response you can find out about the server engine DB.
  •  

miaedwards

The main way SQL injections appear is by entering parameter values directly into the request body (classic 1=1) works like this:

You receive from the client via HTTP the value (' OR 1=1 --)
In the code on the backup, you enter directly into the body of the request and get there NAME = " OR 1=1 ..
SQL parses the request, sees in it the condition for Name and check 1 =1, executes the code exactly as it is written in the request - returns all the strings to the attacker.
In SQL Server, this path is fixed by parameterizing queries. In the request text, only the parameter name is passed, not its value (WHERE Name = @Name). The parameter values themselves are passed separately, and at no point do they fit into the request text. Neither raw nor shielded.

SQL Server makes an execution plan based on the exact text of the query. Regardless of what will be passed to it as the @Name parameter, it will filter by the Name column. 1=1 cannot jump out of the parameter value and get into the query text in any way. And after drawing up the plan ("filter by Name"), at the time of execution of this plan, when passing through the table, the parameter value will be used, and only as a search string, and not as a Boolean expression.

PDO behaves in the same way in the case of non-emulated prepare. Escaping is only used in emulated mode (not a PHP developer, not sure how often it is used). The only difference is that in SQL Server, prepare and parameterization are separated. You can parameterize non-prepared queries, and vice versa.

EF uses parameterized queries internally, so it won't work to push SQL Injection through it. Something can go wrong only if you pull your self-written SQL procedures through EF, in which you will glue dynamic SQL from parameter values. But EF has nothing to do with it.
  •