Trong ứng dụng khi cần tương tác với
database, có lẽ một cách làm rất phổ biến là tạo lập một chuỗi chứa lệnh
SQL, ghép các giá trị nhập vào của người dùng thành một lệnh SQL hoàn
chỉnh, rồi thực hiện chuỗi lệnh SQL đó. Như ví dụ dưới đây:
string cmdStr = "INSERT INTO Customer(Name, Address, Email, Phone) VALUES('" + txtName.Text + "', '" + txtEmail.Text + "','" + txtPhone.Text + "')"; conn.Open();SqlCommand cmd = new SqlCommand(cmdStr, conn);cmd.ExecuteNonQuery(); |
Cách làm này có ưu điểm tiện lợi,
giúp quá trình phát triển code nhanh (không phải chuyển qua lại giữa
Visual Studio và Management Studio). Tuy nhiên nó tiềm ẩn rất nhiều vấn
đề (cách làm tối ưu là viết một thủ tục trong database rồi từ ứng dụng
gọi thủ tục này và truyền các tham số cho nó):
1. An ninh: việc
viết lệnh SQL thẳng trong ứng dụng như vậy sẽ tạo ra lỗ hổng SQL
injection, tức là hacker có thể khéo léo nhập thẳng vào trường text một
chuỗi có chứa đoạn lệnh SQL và để cho database sẽ thực hiện đoạn lệnh
đó. Ví dụ, khi hacker nhập vào trường txtPhone giá trị:
123');delete from order-- |
thì đoạn lệnh mà ứng dụng gửi cho SQL Server sẽ là:
INSERT INTO Customer(Name, Address, Email, Phone) Values('','','123');delete from order--') |
Chú ý là hacker cố tình đưa hai dấu gạch ngang "
--"
vào cuối để biến toàn bộ đoạn ký tự phía sau thành đoạn giải thích. Kết
quả là SQL Server sẽ thực hiện hai lệnh, "INSERT INTO Customer…" và
"delete from order", và bảng order bị xóa sạch. Tương tự hacker có thể
đưa vào các lệnh khác như "drop table order" để xóa hẳn bảng khỏi
database, hoặc "select * from user" để lấy hết thông tin tài khoản của
người dùng.
Nếu dùng thủ tục thì vấn đề hoàn toàn
bị hóa giải, vì toàn bộ giá trị của trường text sẽ được lưu vào cột
tương ứng trong bảng bên trong database. Khi đó chỉ có một lệnh INSERT
được thực hiện và giá trị của Phone của bản ghi mới sẽ là "
123');delete from order--"
2. Hiệu năng (performance):
cách làm trên sẽ dẫn đến mỗi lần thực hiện SQL Server sẽ biên dịch lại
câu lệnh. Khi SQL Server nhận được một câu lệnh, nó sẽ kiểm tra xem câu
lệnh này đã có kế hoạch thực thi lưu trong cache hay chưa. Nó băm (hash)
câu lệnh để chuyển thành một con số và đối chiếu với bảng băm trong
cache, nếu tìm thấy có nghĩa là câu lệnh này đã thực hiện trước đó rồi
và SQL Server dùng luôn kế hoạch thực thi đã có sẵn. Nếu không tìm thấy
có nghĩa đây là câu lệnh mới và SQL Server sẽ biên dịch, tạo kế hoạch
thực thi, lưu vào cache, và thực hiện câu lệnh. Vì với hàm băm, câu lệnh
chỉ cần khác đi một chút (chỉ cần thêm một dấu cách) là đã cho số băm
khác nhau, nên với mỗi giá trị người dùng nhập vào sẽ tạo thành một câu
lệnh mới và SQL Server lại phải trải qua các bước biên dịch, tạo kế
hoạch thực thi, lưu vào cache trước khi tiến hành thực hiện câu lệnh.
Trong nhiều trường hợp, chi phí cho
các bước kể trên có thể rất lớn. Ví dụ với một câu lệnh mất 100 mili
giây để biên dịch trong khi cũng mất 100 mili giây để thực hiện, thì chi
phí để thực hiện câu lệnh này bị tăng gấp đôi. Một hậu quả khác là mỗi
lần biên dịch thì kế hoạch thực thi mới sẽ chiếm chỗ trong cache, trong
khi kích thước của cache chỉ có hạn. Đến một lúc kế hoạch thực thi của
các câu lệnh khác sẽ bị loại khỏi cache để giải phóng chỗ, và đến khi
các câu lệnh khác đó được thực hiện thì lại cần biên dịch lại. Như vậy
hiệu năng của toàn bộ hệ thống bị giảm.
Khi dùng thủ tục thì tình huống sẽ
thay đổi hẳn, vì SQL Server chỉ băm câu lệnh gọi đến thủ tục mà bỏ qua
các tham số, cho nên khi đã thực hiện EXEC Proc1 @param=1 thì đến khi
gặp EXEC Proc1 @param=2 SQL Server không cần biên dịch lại thủ tục nữa.
3. Bảo mật: Khi
ta viết thẳng lệnh SQL vào ứng dụng như trên thì user được dùng để kết
nối vào database (trong connection string) cần phải có quyền INSERT vào
bảng. Thông thường các ứng dụng có đủ các thao tác đọc/ghi/xóa vào
database, cho nên user trên cũng đòi hỏi đủ các quyền
SELECT/INSERT/UPDATE/DELETE vào các bảng trong database. Khi hacker
chiếm được quyền truy nhập vào database với user trên, hắn ta có thể mặc
sức tung hoành làm bất cứ điều gì hắn muốn trong database.
Khi dùng thủ tục thì user không cần
bất cứ quyền nào trực tiếp trên bảng, user chỉ cần quyền thực thi thủ
tục và khi chạy thì thủ tục thực hiện các thao tác trên bảng cho user.
Ta có thể dỡ bỏ hết các quyền của user trên tất cả các bảng và chỉ cấp
quyền thực thi trên các thủ tục cần thiết. Ta cũng có thể đồng thời dỡ
bỏ quyền truy nhập vào các bảng hệ thống, cho nên nếu hacker có truy
nhập được vào database thông qua user trên, hắn ta sẽ mù tịt không biết
database có các bảng nào để mà phá.
Nếu hắn truy nhập được vào mã nguồn
của ứng dụng thì có thể biết được tên của các thủ tục được dùng trong
ứng dụng và chạy các thủ tục này, nhưng mức độ phá hoại của hacker bị
khống chế ở mức thấp hơn nhiều so với khi user có đủ các quyền.
4. Bảo trì: thường
có những đoạn lệnh SQL được dùng lại ở một vài nơi khác nhau trong ứng
dụng, hoặc thậm chí ở các ứng dụng khác nhau truy nhập chung vào một
database. Khi viết thẳng SQL code trong ứng dụng ta sẽ phải viết lại
đoạn lệnh trên ở tất cả những nơi nó được dùng. Điều này đã phạm vào lỗi
"lặp lại code" (duplication of code) trong phát triển phần mềm. Khi cần
phải sửa lại câu lệnh SQL trên (vì lỗi hoặc cần viết theo cách tối ưu
hơn, hoặc cấu trúc database thay đổi dẫn đến cần viết lại) ta sẽ phải
tìm đến tất cả các nơi có dùng câu lệnh SQL đó để sửa.
Với thủ tục thì ta chỉ cần sửa ở một
nơi và nó có tác dụng cho toàn ứng dụng. Giống như .net tách mã chương
trình ra khỏi mã html, dùng thủ tục cũng tách mã SQL ra khỏi mã chương
trình. Lúc đó thủ tục có chức năng như là cổng truy nhập, hay API, mà
qua đó ứng dụng giao tiếp với database. Nó tạo thành một lớp ngăn cách
giữa ứng dụng và database, và che dấu toàn bộ cấu trúc database khỏi ứng
dụng. Ứng dụng không cần biết database gồm có những bảng gì, mỗi bảng
có các cột nào, hay các bảng quan hệ với nhau ra sao. Vì thế ta có thể
dễ dàng thay đổi cấu trúc của database khi cần và sửa lại các thủ tục có
liên quan mà không ảnh hưởng gì đến ứng dụng.
Kết luận:
Việc viết mã SQL trong ứng dụng có rất nhiều vấn đề như đã chỉ ra. Với
những ứng dụng nhỏ hoặc ứn dụng có những đặc thù nhất định, những vấn đề
trên có thể không bộc lộ hết ra, nhưng khi ta quyết định chọn phương
pháp này thì cũng cần ý thức được những hệ quả có thể xảy ra của nó. Có
những trường hợp ta không muốn lưu mã nguồn trong database, ví dụ để ứng
dụng có thể dễ dàng chuyển đổi giữa các hệ CSDL khác nhau. Khi đó ta
bắt buộc phải viết SQL code trong ứng dụng, nhưng để giảm nhẹ các vấn đề
của nó, ta nên dùng chuỗi SQL có tham số (dùng cmd.Parameters.Add) để
tránh được lỗi SQL injection và biên dịch lại câu lệnh (điểm 1 và 2 ở
trên). Còn khi ta có lựa chọn dùng thủ tục thì nên áp dụng phương pháp
này. Đây là phương pháp mà Microsoft khuyến cáo khi viết ứng dụng trên
môi trường phát triển của họ
