Mitigating SQL Injection Attacks in a Parameterized Report
Hossein.K
6,642
Like
Share
Report
In any report that includes a parameter of type String, be sure to use an available
values list (also known as a valid values list) and ensure that any user running the
report has only the permissions required to view the data in the report. When you
define a parameter of type String, the user is presented with a text box that can
take any value. An available values list limits the values that can be entered. If
the report parameter is tied to a query parameter and you do not use an available
values list, it is possible for a report user to type SQL syntax into the text box,
potentially opening the report and your server to a SQL injection attack. If the
user has sufficient permissions to execute the new SQL statement, it may
produce unwanted results on the server.
If a report parameter is not tied to a query parameter and the parameter values are
included in the report, it is possible for a report user to type expression syntax or
a URL into the parameter value and render the report to Excel or HTML. If
another user then views the report and clicks the rendered parameter contents, the
user may inadvertently execute the malicious script or link.
To mitigate the risk of inadvertently running malicious scripts, open rendered
reports only from trusted sources.
Regards,
Hossein Karimi
values list (also known as a valid values list) and ensure that any user running the
report has only the permissions required to view the data in the report. When you
define a parameter of type String, the user is presented with a text box that can
take any value. An available values list limits the values that can be entered. If
the report parameter is tied to a query parameter and you do not use an available
values list, it is possible for a report user to type SQL syntax into the text box,
potentially opening the report and your server to a SQL injection attack. If the
user has sufficient permissions to execute the new SQL statement, it may
produce unwanted results on the server.
If a report parameter is not tied to a query parameter and the parameter values are
included in the report, it is possible for a report user to type expression syntax or
a URL into the parameter value and render the report to Excel or HTML. If
another user then views the report and clicks the rendered parameter contents, the
user may inadvertently execute the malicious script or link.
To mitigate the risk of inadvertently running malicious scripts, open rendered
reports only from trusted sources.
Regards,
Hossein Karimi
*This post is locked for comments