E In the stored procedure save only the result of LEFTCompanyInput10 to the

E in the stored procedure save only the result of

This preview shows page 26 - 28 out of 129 pages.

E. In the stored procedure, save only the result of LEFT(“CompanyInput,10) to the database column. F. In the stored procedure, save the result of REPLACE(@CompanyInput,”@-]”,””) to the database column. Answer: A, C Explanation It is best for the approach that you must validate and cleanse data before it is used and/or store. Rule number two is: data must be validated as it crosses the boundary between untrusted and trusted environments. By definition, trusted data is data you or an entity you explicitly trust has complete control over; untrusted data refers to everything else. In short, any data submitted by a user is initially untrusted data. When it comes to SQL statements, all dynamic SQL is bad, and paramterized store procedures must be used. Dynamic SQL can be easily compromised and used for SQL injection attacks. Validate SQL Input and Use Parameter Objects Validate all the input data that you use in SQL commands. Do not permit the client to retrieve more data than it should. Also, do not trust user input, and do not permit the client to perform operations that it should not perform. Doing so helps to lower the risk of SQL injection. By rejecting invalid data early before you issue a command that has the invalid data, you can improve performance by eliminating unnecessary database requests. Use Parameter objects when you build database commands. When you use Parameter objects, each parameter is automatically type checked. Checking the type is another effective countermeasure you can use to help prevent SQL injection. Ideally, use Parameter objects in conjunction with stored procedures to improve performance. For more information about using parameters, see "Parameters" later in this chapter. Using Parameters with Stored Procedures The following code sample illustrates how to use the Parameters collection. SqlDataAdapter myCommand = new SqlDataAdapter("AuthorLogin", conn); myCommand.SelectCommand.CommandType = CommandType.StoredProcedure; SqlParameter parm = myCommand.SelectCommand.Parameters.Add( "@au_id", SqlDbType.VarChar, 11); parm.Value = Login.Text; In the code sample, the @au_id parameter is treated as a literal value and not as code that can be run. Also, the parameter is checked for type and length. In the code fragment, the input value cannot be longer than 11 characters. If the data does not conform to the type or length that is defined by the parameter, an exception is generated. Using stored procedures alone does not
Image of page 26