<asp:CheckBox ID="chkIsHidden" runat="server" Enabled="false"
Checked='<%# Convert.IsDBNull(Eval("Is_Hidden")) ? false : Convert.ToBoolean(Eval("Is_Hidden")) %>'
/>
Above code, Security program scan and alert that "Blind SQL Injection", I'm so confuse
Why it has SQL injection?
How to fix to avoid sql injection?
As you can see, even if your Web application does not return error messages, it may still be susceptible to blind SQL injection attacks. However, you can protect your organization's applications against attacks with the following best practices:
Create a policy that enforces secure coding practices to ensure vulnerability detection and assessments are performed during any application development or deployment.
Have your developers identify where data enters or exits the application and ensure that validation occurs for every part of the HTTP request before letting it anywhere near scripts, data access routines and SQL queries. This will prevent user-supplied data from being able to modify the syntax of SQL statements.
Completely isolate your Web applications from SQL using stored procedures, which the application should execute using a safe interface, such as JDBC's CallableStatement or ADO's Command Object. If SQL statements must be generated on the fly, use PreparedStatements, as both PreparedStatements and stored procedures compile the SQL statement before the user input is added, making it impossible for user input to modify the actual SQL statement.
Consider using a vulnerability assessment tool to automate the discovery of SQL injection and other security vulnerabilities.
Develop an incident response plan. Having a detailed and well-rehearsed plan will help you handle any attack that occurs in an orderly and effective manner, and minimize the impact to your organization.
Related
I had added the Extended event to track sql calls which is slowing down my system leading to Timeout exceptions and other
CREATE EVENT SESSION [longrunning_statements] ON SERVER
ADD EVENT sqlserver.sql_statement_completed(
WHERE ([duration]>(2000000) AND [database_id]=(9)))
ADD TARGET package0.event_file(SET filename=N'c:\capture\xe_longrunning_statement.xel',metadatafile=N'c:\capture\xe_longrunning_statement.xem')
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO
But i noticed it does not register sql server updates/read queries/procedures calls from Entity Framework but only logged my sql queries run using SSMS.
Any ideas are appreciated
UPDATE:
I use EF6.1 which used i think batches to save data.
Instead of trying to capture sqlserver.sql_statement_completed I would capture sqlserver.sql_batch_completed and sqlserver.rpc_completed for application/API issued queries/stored procedures.
If that does not work then removing the filters(or at least the duration filter (as Andrey is suggesting in the comments) would probably give us more insight on why the queries are not being captured.
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 noticed that SQL Server Profiler includes an event when I use a deprecated feature:
Occurs when you use a feature that will be removed from future version of SQL Server, but will not be removed from the next major release of SQL Server. For greatest longevity of your applications, you should avoid using features that cause the Deprecation Announcement event class or hte Deprecation Final Support event class.
I turned it on and just before any Login event is recorded, I get:
Deprecated encryption algorithm rc4 will be removed in a future version of SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use it. Use stronger algorithms instead.
But I'm not using RC4! I'm not even using AES. I'm using nothing. I'm just connecting to SQL Server.
Or am i?
Bonus Chatter
SQL Server, Deprecated Features Object
Deprecated encryption algorithm
Deprecated encryption algorithm rc4 will be removed in the next version of SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use it. The RC4 algorithm is weak and is only supported for backward compatibility. New material can only be encrypted using RC4 or RC4_128 when the database is in compatibility level 90 or 100. (Not recommended.) Use a newer algorithm such as one of the AES algorithms instead. In SQL Server 2012 material encrypted using RC4 or RC4_128 can be unencrypted in any compatibility level.
Am I even doing anything wrong?
I'm simply opening a connect to SQL Server:
String connectionString =
"Provider=SQLOLEDB;Network Library=DBMSSOCN;Data Source=helium;
User ID=Contoso;Password=correctbatteryhorsestaple"
var conn = new ADOConnection();
conn.ConnectionString = connectionString;
conn.Open()
Even though the description of the event says:
occurs when you use a feature that...
Is it possible it is generated when I'm not using a feature? Is it possible this warning:
occurs when anyone logs in regardless of they are using RC4
and is actually just an announcement? Another application, an ASP.net MVC ADO-EF (a completely different connection technology) gets the same error.
The documentation of other deprecation warnings give when you would see them:
Occurs once per compilation.
Occurs once per query.
Occurs once per use in a DDL statement.
Event occurs once per database start and once per collation use.
Occurs once per use.
Whereas the documentation for this warning doesn't mention when you would see it.
Avoid using this feature in new development work, and plan to modify applications that currently use it.
How do I avoid RC4 in future work, when I can't figure out where I'm using it now?
Profile your 2008 R2 server. Do you get it?
☒ Yes
☐ No
Are SQL Server authentication passwords stored using RC4?
No. SQL Server passwords are not stored using reversible encryption. The passwords are salted and hashed using SHA-1:
hashBytes = 0x0100 + fourByteSalt + SHA1(utf16EncodedPassword+fourByteSalt)
In SQL Server 2012, they switched to SHA2 over SHA-1.
This happens on all my 2008 R2 Servers as well, it seems to happen any time that a connection is made using a SQL login, I can't seem to find any documentation on why this would be the case, I can only presume that internally SQL Server is using RC4 somewhere in the login process, so it's nothing that you are doing in your code.
There aren't any options that I know of to change this behaviour and it doesn't seem to cause any issues so I wouldn't worry about it.
I haven't seen this behavior, however.... when I call a procedure named: verifyPassword 'secret' (for example) the string secret gets commented out by the profiler. Because the string 'Password' triggers some 'pssstttt don't reveal this one' algorithm.
My fair guess that this is also the case when warning for deprecated functions.
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%".
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.