Client query data phía server bằng câu lệnh SQL

maye · December 17, 2022, 5:36pm

Em đang làm một blog ạ.

Client truy cập vào enpoint REST web API như: HTTP GET myweb.com/api/topic/categorys để lấy list categorys JSON về làm menu.
Hoặc triển khai Odata chuẩn RESTful như: HTTP GET myweb.com/Odata/serviceRoot/Airports?$filter=contains(Location/Address, 'San Francisco')
Client cũng có thể áp dụng GraphQL để search, sort, filter, … data phía server.

Khi server nhận được request, cho dù server có sử dụng ORM gì đi nữa thì đích đến cuối cùng vẫn là execute câu lệnh native SQL, vậy tại sao dev frontend không viết câu lệnh SQL tại client luôn cho tiện

Vậy là em đã cho javascript tại browser gửi http post với body là câu lệnh select SQL. Server nhận được chuỗi string này liền execute ngay và response hết những gì mà database return về . Thông thường em phải mở 3 tab:

1 tab mở tool database management studio để xem quan hệ bảng.
1 tab viết backend, định nghĩa URL cho web API.
1 tab code frontend phải nhìn xem backend định nghĩa cách lấy data như thế nào.

Hiện tại em chỉ cần mở 2 tab để code thôi

1 tab mở database xem bảng.
1 tab viết frontend nhưng không cần nhìn sang file controller của backend nữa mà nhìn sang database luôn.

Có 2 vấn đề xảy ra:

Web sẽ bị lộ thông tin, vì hacker được phép SELECT * FROM tất cả các bảng, nhưng đây là blog, toàn những bảng public như TOPIC, COMMENT, IMAGE, .... trong DB có bao nhiêu data đều show ra hết rồi, nếu xem được table USER thì password cũng đã bị hash hết rồi. Crawl cũng đủ lấy được hết data trong DB không cần hack.
=> Tạm bỏ qua issue này, thêm nữa là hacker không hứng thú với data blog, cũng không rảnh để hack những web nhỏ.

SQL injection hoặc client thực thi câu lệnh CREATE, UPDATE, DELETE, ...
=> Em fix bằng cách:
– Viết function xử lý chuối SQL sao cho chỉ cho phép câu lệnh SELECT thôi.
– Khi client muốn chỉnh sửa data thì vẫn làm theo cách thông thường, có validate JWT.

Hiện tại web em đã go live được 1 tháng rồi, mỗi ngày có khoảng 100 lượt truy cập (theo google analytics) nhưng vẫn chưa bị hack vì hacker sẽ không ngờ tới trên đời này lại có người thiết kế quái dị như thế này

Em muốn hỏi nếu cứ tiếp tục như này thì web em còn lỗi bảo mật tìm ẩn nào nữa không nếu em vẫn tiếp tục làm liều như thế này?

Em cảm ơn.

trigia · December 17, 2022, 7:40pm

nếu bạn ko có 1 server để quản lý connection, và tiền xử lý thì đoạn này bạn làm thế nào? viết nó vào file js ? rồi người dùng tải file js đó về sửa thì cũng như ko

thêm nữa nó mà chơi trò ddos thì ốm luôn vì cho nó, kết nối thẳng vào dataserver

maye · December 17, 2022, 7:58pm

Có cho client kết nối thẳng vào DB đâu bạn, validate này mình viết ở backend chứ, mục đích là để bảo vệ server mà bạn.

client <=====> web server <=======> database server

mà cách của mình không liên quan ddos lắm, vì khi ddos thì kiến trúc nào cũng bị sập cả mà. Thực tế thì không ai ddos blog người bình thường cả.

trigia · December 17, 2022, 8:35pm

à vậy thì cũng đc, làm web đơn giản,nếu ko sợ bị bọn hacker chọt phá, còn nếu bọn nó có chọt phá đc thì mình cũng ko biết đc, rồi ở trên bạn nói ko cần orm, vậy sau khi querry dữ liệu ở dạng raw sao bạn mapping ra thành dạng có cấu trúc như bạn mong muốn đc?, mà có thể ít bảng và csdl đơn giản thì cũng đc dùng dạng nosql json cũng đc, chứ csdl to thì bắt buộc phải dựng 1 cái orm cho nó

maye · December 17, 2022, 8:44pm

À phần tạo DTO, entity nếu backend là JavaScript thì không cần DTO để mapping, case của mình backend là ASP,NET khi kết nối đến csdl có lệnh để migration tự động tạo class entity để mapping với bảng luôn nên mình không đề cập. Blog cá nhân thì CSDL không thể to được bạn, quanh quẩn chắc khoảng 10 table nếu tính luôn table comment không sử dụng plugin commnet của facebook.

rogp10 · January 7, 2023, 12:16pm

“Đạo cao 1 thước, ma cao 1 trượng”, cho client tạo query là không ổn rồi. Cách chặn injection tối ưu là tách riêng những gì người dùng đưa vào với lệnh chính, hay parametrized SQL.