A great demo of the canvas element
Canvas Ajax Demo
Details on the use of the canvas element.
A SQL Injection Attack is one of the many security issues that must be address when designing and developing applications that access a database. The injection vulnerability is potentially present on pages or forms where the user must enter a value to be submitted to the server. If the user input is not properly validated and the database doesn’t protect itself then SQLiA can occur. I have posted a sample application under the Demos link in the Downloads section of the mail portal. To download the SQL Injection Attack Sample Web Site and SQL Script click here: VB.Net Version orC# Version To run this demo code you will need Visual Studio 2008 or higher and SQL Server 2000 or higher installed
SQL Injection Demo:
The SQLInjectionDemo.zip file consists of a T-SQL Script file named CustomerOrdersDB_SQLInjection.sql used to create the database, tables (including sample data) and stored procedures (Stored procedures were created usingCRUD Script) and a Visual Studio 2008 project called Demo.sln. The Visual Studio Solution contains 2 pages: SQLInjection.aspx and SQLInjectionFixed.aspx that as the names imply illustrate a page that is vulnerable to SQL Injection and one that is not (not all possible SQL injection attacks are prevented but most).
To test the search feature that’s vulnerable to SQL Injection:Open the Solution (Demo.sln)Select SQLInjection.aspx in the Solution ExplorerPress Ctrl + F5 or Select Start without Debugging from the Debug menuType Antoine into the search boxPress the Search button
Note: You will notice that the results displayed on the page are filtered to show only Antoine Victor. Try a couple more searches then continueCopy the injection statement from the bottom of the pagePaste into the search boxPress the Search button
Note: You will see a list of all of the tables defined in the current database and all columns defined in those tables. Think credit card table, employee table with Social Security Numbers. Armed with this information a hacker could use the same SQL Injection vulnerability in this page to then request columns and rows from the credit card or employees table.
Fortunately there is a relatively easy fix for this. The fix is a 2 part process, first we validate the user input before sending it to the server and removed any special characters or malicious code, and second we make all calls to the database through stored procedures (created automatically usingCRUD Script or theSSMS Toolkit)
To see the page with the Injection issue resolved in the current browser window navigate to SQLInjectionFixed.aspx and follow the previous steps. This SQL Injection issue is now resolved.
For a list of other common injection attacks to test with this demo see: SQL Injection Cheat Sheet.
YouTube Demo showing the SQL Injection Fix:
In SQL 2000 and before setting auto file growth to a percentage meant that the file would grow by 10% of the initial file size (regardless of how large the file had grown since its creation).
In SQL 2005 and later the growth by percentage setting is based on the “current” file size and not the “initial” file size. The means the amount that the file grows will vary greatly from the time that the file is created to its size 2 years later.
The ProDataMan way
In SQL 2005 and later do not use a percentage setting used a fixed Megabyte setting based on the amount of data that your users typically add between maintenance periods.
I was just made aware of a new bug (oops I mean undocumented feature) in SQL 2005 that prevents the backup of File Groups that scroll beyond the viewable area of the Backup Dialog box.
This is not a problem if you have only a few file groups but if you have enough that you can’t see them all without scrolling then you will only be able to back up the ones that you can see before you touch the scroll bar.