Archive

Posts Tagged ‘web’

How to protect against SQL injection attacks

June 3, 2011 Leave a comment

SQL injection is the act of injecting some characters (e.g. SQL) into a SQL statement causing it to perform an unintended (e.g. malicious) action.  It most often occurs when some criteria fed to the query is provided by user input (or is editable by a user – say the querystring in a URL or a field on a web form).

A number of things contribute to making this type of attack possible including: 1) insecure code, 2) unnecessarily highly privileged database access accounts.

Things you can do to protect against SQL injection:

  1. DO NOT execute any T-SQL by concatenating values, particularly where user input is involved
  2. Use parameterized SQL instead – this ensures that values are escaped such that a T-SQL command cannot be terminated
  3. Use stored procedures where the T-SQL is static and criteria values are passed in as parameters (then use in conjunction with point 2 above)
  4. Do not grant your database accounts used by your application unrestricted access to databases.  DO NOT grant them DBO rights in a production OR test environment.  This is a HUGE BENEFIT of stored procedures.  Stored Procedures can be granted execute rights and SQL Server’s chaining system (known as ownership chains) will automatically allow those operations to run against objects (e.g. tables) without explicit rights there.  Grant rights directly to tables only if application code must run SQL directly.  Even then pay attention to SELECT vs UPDATE rights.

References:

  1. How To: Protect from SQL Injection in ASP.NET (MSDN article from Microsoft Patterns & Practices)
  2. SQL Injection (MSDN article with great tips on protecting against this)

-Krip

Poor user interface – learn from their mistakes!

June 1, 2011 Leave a comment

Just went through a website registration process where I’m left uncertain if the registration succeeded or not.  A look under the covers leads me to believe it did complete successfully.  I will explain further but note that I’m not here to expose the source but to provide education for developers so we get more intuitive user interfaces with proper visual clues on what went through and what didn’t!!  The term affordance has evolved to mean “easy discoverability of possible actions”.  And false affordance “leads to mistakes and misunderstandings”.  I think they apply in this case.

I filled out a form, clicked submit, then a pop-up appeared.  Correction: a pop-up tried to appear.  I must enable that in my browser.  The pop-up appeared, I entered the CAPTCHA, and then a message box appears indicating that ‘my email was sent’.  The pop-up closed and I’m left on the original form with a red message indicating asterisk denotes a mandatory field!  Huh?  What do I do?

Here are the UI mistakes:

  • UI mistake number 1: When the pop-up didn’t appear I was left wondering if I’ve already lost the game.
  • UI mistake number 2: What “email”?  I’m not writing an email.  So now I’m further confused.
  • UI mistake number 3: I’m left on the data entry form with all my data filled in and a red star next to mandatory fields, all of which I’ve filled out!  What do I do now?

My suggestions for fixing:

  • Don’t do pop-ups as there are lots of pop-up blockers out there.
  • Remove references to “email” – say something like “your request has been submitted”.
  • Move users off the form if they’ve submitted it successfully.
  • Send users an email so they have a receipt of their submission.

As a final note, I peaked under the hood at the HTML source behind the pop-up – the JavaScript alert (message box) appeared BEFORE a method was called that submitted the form fields to the server.  BIG MISTAKE!  The submission should happen and THEN the user be given confirmation.

OK, one more: the complete CAPTCHA system can be defeated by analyzing the HTML of that pop-up 🙂  But we’ll leave security for another post.

-Krip