1. string dataDir = AppDomain.CurrentDomain.BaseDirectory;
   
2. if (dataDir.EndsWith(@"\bin\Debug\")
   
3. || dataDir.EndsWith(@"\bin\Release\"))
   
4. {
   
5. dataDir = System.IO.Directory.GetParent(dataDir).Parent.Parent.FullName;
   
6. AppDomain.CurrentDomain.SetData("DataDirectory", dataDir);
   
7. }
   
8. string str = @"Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\db5.mdf;Integrated Security=True;User Instance=True";
   
9. using (SqlConnection conn = new SqlConnection(str))
   
10. {
    
11. conn.Open();
    
12. 
    
13. using (SqlCommand cmd =conn.CreateCommand())
    
14. {
    
15. string name =txtName.Text;
    
16. string password =txtPassword.Text;
    
17. 
    
18. cmd.CommandText = "select count(*) from T_user where username =@name and password =@password";
    
19. cmd.Parameters.Add(new SqlParameter("name",name));
    
20. cmd.Parameters.Add(new SqlParameter("password",password));
    
21. //int i =()cmd.ExecuteNonQuery();
    
22. int i= (int)cmd.ExecuteScalar();
    
23. if (i>=1)
    
24. {
    
25. MessageBox.Show("登录成功");
    
26. }
    
27. 
    
28. 
    
29. 
    
30. }

复制代码

在用户的输入没有为转义字符过滤时，就会发生这种形式的注入式攻击，它会被传递给一个SQL语句。这样就会导致应用程序的终端用户对数据库上的语句实施操纵。比方说，下面的这行代码就会演示这种漏洞：

statement := "SELECT * FROM users WHERE name = '" + userName + "'; "

这种代码的设计目的是将一个特定的用户从其用户表中取出，但是，如果用户名被一个恶意的用户用一种特定的方式伪造，这个语句所执行的操作可能就不仅仅是代码的作者所期望的那样了。例如，将用户名变量(即username)设置为：

a' or '1'='1，此时原始语句发生了变化：

SELECT * FROM users WHERE name = 'a' OR '1'='1';

如果这种代码被用于一个认证过程，那么这个例子就能够强迫选择一个合法的用户名，因为赋值't'='t永远是正确的。

这个是一个很早以前的SQL 注入方式，无论你程序正常的SQL 语句是什么 Where条件后面跟一个 or '1'='1' 黑客让自己的代码改变整个代码的运行结果，永远都是正确的判断，所以这就是为什么会出现SQL 参数化参数的原因！

SQL注入主要是SQL语句的拼接，不管这种还是别的只要拼接对了，就可以执行，利用这种方法 来提权
能掉到权，可以服务上随便大小便了，可以限定URL请求长度来防，

呵呵，我这边的编程思想是将文本框中的用户名密码整体获取成字符串后转成base64码，这样处理后就不存在引号了，然后再放入到sql语句中验证。呵呵,引号都转码了