I need to prevent the user from entering the characters that may result in malfunctioning of the Database. I'm using stored procedures for the reports. I need to validate the the textbox parameter for the purpose. Any one please guide me on how can i do this.
Restrict access to your report where possible
Use a limited SQL Server reporting account that only has restricted read only access to the tables it requires
Where sensible, limit user selection to drop down lists
If you wrapping the report inside a programming language like c#, you can use Validators on the input and parameterised queries.
If you passing ssrs parameters directly to your stored procedure and worried that text injection may occur, pass the parameter for unexpected patterns within SQL prior to utilising i.e. a user id that has the expected format of "A3290RE" can be checked for spaces with CONTAINS and verified for length with LEN to prevent a user entereing "A3290RE ' or name like '%a%".
Related
I have a dynamic report built using PL/SQL function returning SQL, I allow the user to enter some variables and I construct the SQL statement dynamically. I also format the background color according to a column value using JavaScript dynamic action on page load. What I need to do is to add a button to send the generated report via email (in the email body not as attachment) to a specific address. I would hugely appreciate assistance on how to do this.
If not already done, you'll want to move the logic that generates the SQL query to a stored function so it can be called from more than one place. Then you'll want to create a new PL/SQL function that returns the data as an HTML table.
This isn't as trivial as it seems at first. You'd need to send the CSS along with the HTML - and some mail clients require inline CSS. There are some tools to help you line the CSS, such as this one: https://templates.mailchimp.com/resources/inline-css/
Once that's in place, you can use it to get the HTML for the table and add it to an email body.
Regarding the dynamic SQL, this can often lead to SQL injection vulnerabilities if you're not careful. If you share that code with us (after changing the names of tables and other identifiers), we can help ensure it's safe.
What should an Incident Handler do (or) follow when an SQL injection attack is reported?
Initial Response
Analysis
Action
Aiming to make a Procedure guide to follow for myself and my team.
Brief or detail, anything would help.
Not a full process, but it should get you started:
Initial Response
Verify that the reported vulnerability is legitimate, preferably in a production-safe manner
See the OWASP SQL Injection Testing guide for more information on how to do this
Analysis
Determine the cause of the SQL Injection
This is probably a location where user input is directly concatenated into a SQL query
Action
The best defense against SQL Injection is to utilize parameterized/prepared statements instead of direct string concatenation when building a query based on user input.
These statements provide a clear divide between data and syntax, so that user input is never treated as SQL syntax but instead treated as data
How you do this will depend on the language and framework used in your application
See the OWASP SQL Injection Prevention Cheat Sheet for more information on preventing SQL injection
I am currently storing data submitted from users into my database already encoded like such:
<cfquery>
INSERT INTO dbo.MyTable (UserID, Comment)
VALUES
(
<cfqueryparam value="#FORM.UserID#" cfsqltype="cf_sql_integer"/>,
<cfqueryparam value="#EncodeForHTML(FORM.Comment)#" cfsqltype="cf_sql_nvarchar"/>
)
</cfquery>
Evidently this is not the right way to do it because now I have escaped characters in my DB table which are only useful for HTML output and difficult to perform searches on within SQL Server.
So how do I ensure that I apply the EncodeForHTML() on the input before it hits the server and then Canonicalize() the data received to be stored in the DB?
Mitigate potentially DB-harmful text when it heads towards the DB: pass it as a parameter, not hard-coded into the SQL statement, as you have kinda done in your example. You are still exposing yourself by not parameterising your ID value. As a rule, only SQL should go in your <cfquery>'s SQL string; any data values should be passed as parameters.
Similarly, mitigate risk your user-provided data might expose when you use the data. Not when it goes into storage, but when you actually use it. encodeForHtml() is only appropriate for stuff being written into HTML. It's no help if it's being passed on a URL, or used in JavaScript, etc. There are different mitigation approaches for those (urlEncodedFormat() and encodeForJavaScript() respectively). The point being you handle the mitigation on a use-by-use basis, not just generically.
And how to ensure this is done (you ask this)? Well... you write your code diligently and have a rigorous code review and QA process (with QA doing pen. tests).
You can store them as is, and use <cfqueryparam> for form.userid as well. On output, you use encodeforhtml().
If you prefer to have some data sanitizing done before storing, try AntiSamy (built-in in CF11) http://www.adobe.com/devnet/coldfusion/articles/security-improvements-cf11.edu.html#articlecontentAdobe_numberedheader_2
Suppose I have a .NET HttpModule that analyzes incoming requests to check for possible attacks like Sql Injection.
Now suppose that a user of my application enters the following in a form field and submits it:
' OR 1=1
That is Unicode for ' OR 1=1. So in the request I get something like:
http://example.com/?q=%26%23039%26%23032%26%23079%26%23082%26%23032%26%23049%26%23061%26%23049
Which in my HttpModule looks fine (no Sql Injection), but the server will correctly decode it to q=' OR 1=1 and my filter will fail.
So, my question is: Is there any way to know at that point what is the encoding used by the request query string, so I can decode it and detect the attack?
I guess the browser has to tell the server which encoding the request is in, so it can be correctly decoded. Or am I wrong?
the server will correctly decode it to q=' OR 1=1
It shouldn't. There is no valid reason(*) an application would HTML-decode the '... string before using it in an SQL query. HTML-decoding is a client-side occurrence.
(* there's the invalid reason: that the application author doesn't have the foggiest idea what they're doing, tries to write an input-HTML-escaping function - a misguided idea in the first place - and due to incompetence writes an input-de-escaping function instead... but that would be an unlikely case. Hopefully.)
Is there any way to know at that point what is the encoding used by the request query string
No. Some Web Application Firewalls attempt to get around this by applying every decoding scheme they can think of to the incoming data, and triggering if any of them match something suspicious, just in case the application happens to have an arbitrary decoder of that type sitting between the input and a vulnerable system.
This can result in a performance hit as well as increased false positives, and doubly so for the WAFs that try all possible combinations of two or more decoders. (eg is T1IrMQ a base-64-encoded, URL-encoded OR 1 SQL attack, or just a car numberplate?)
Quite how far you take this idea is a trade-off between how many potential attacks you catch and how much negative impact you have on real users of the app. There's no one 'correct' solution because ultimately you can never provide complete protection against app vulnerabilities in a layer outside the app (aka "WAFs don't work").
What you are seeing is URL Encoded, where a percent sign followed by 2 hex digits represents a single encoded byte octet. In HTML, an entity starting with an ampersand and ending with a semicolon contains an entity name or an explicit Unicode codepoint value.
What gets sent over the wire between the browser and server is http://example.com/?q=%26%23039%26%23032%26%23079%26%23082%26%23032%26%23049%26%23061%26%23049, but logically is actually represents http://example.com/?q=' OR 1=1 when decoded by the server upon receiving it. When your code reads the query string, it should be receiving ' OR 1=1. The server should not be decoding that any further to ' OR 1=1, you would have to do that in your own code.
If you are allowing a URL query string to specify an SQL query filter as-is, then that is a mistake on your part to begin with. That suggests you are building SQL queries dynamically instead of using parameterized SQL queries or stored procedures, so you are leaving yourself open to SQL Injection attacks. You should not be using that. Parameterized SQL queries and stored procedure are not subject to injection attacks, so your clients should only be allowed to submit the indiviudal parameter values in the URL. Your server code can then extract the individual values from the URL query and pass them to the SQL parameters as needed. The SQL Engine will make sure the values are santitized and formatted to avoid attacks. You should not be handling that manually.
What should considered to prevent Injection in request forms ?
e.g : using Recaptcha, preventing SQL Injections, etc ... what other item should be consider ?
sanitize all your inputs. all only the required stuff.
always use POST as the method in your form.
in your server side scripting, anything that got from user should not be directly input to query. retrieve value from db and do the comparison or any other relevent action
Parameterized queries are a must.
You should also validate your input, both on the client and server sides, prior to binding.
Recaptcha, like any other CAPTCHA is a mechanism to identify someone as human. This has nothing to do with SQL injection.
In order to prevent SQL injection attacks, the best form of defense is to use data access libraries as these contain anti SQL injection measures.
You should alway use parameterized queries and never simply build up a SQL string yourself and pass that to the database.