Đồ án Nghiên cứu các điểm yếu an ninh ứng dụng web

ơn lỗi này và lấy được toàn bộ các thông tin trong cơ sở dữ liệu. 2.1.8 Lưu trữ thiếu an toàn Đa số các ứng dụng web cần lưu trữ dữ liệu nhạy cảm, trong cơ sở dữ liệu hoặc trong một tập tin nào đó trong hệ thống. Thông tin nhạy cảm bao gồm: mật khẩu, số thẻ tín dụng, thông tin tài khoản, hoặc các thông tin cần bảo vệ khác. Các cơ chế mã hóa thường được sử dụng để bảo vệ những thông tin này. Mặc dù sử dụng các hàm mã hóa không khó cho các lập trình viên, tuy nhiên, lập trình viên vẫn thường mắc những lỗi cơ bản khi áp dụng vào ứng dụng web do không hiểu rõ hết các đặc điểm mã hóa. Hình 11 Lưu trữ thiếu an toàn Những lỗi thông thường bao gồm:  Không mã hóa dữ liệu quan trọng như khóa, certificates và mật khẩu Lưu trữ các khóa bảo mật trong bộ nhớ bằng các cơ chế không an toàn Cơ chế tạo số ngẫu nhiên không đảm bảo Sử dụng sai thuật toán Tạo một thuật toán mã hóa không đảm bảo  Hậu quả của những điểm yếu này có thể rất nghiêm trọng đến an toàn của một trang web, cho phép hacker lấy được toàn bộ các thông tin quan trọng được lưu trữ.  2.1.9 Từ chối dịch vụ Ứng dụng web rất dễ bị tổn thương do các cuộc tấn công từ chối dịch vụ (DoS). Tấn công từ chối dịch vụ vào ứng dụng web được định nghĩa là các tấn công làm tê liệt ứng dụng, làm cho các truy cập hợp lệ không thể được tiến hành.  Đa số máy chủ web chỉ có thể xử lý hỗ trợ một số lượng nhất định người sử dụng trong điều kiện bình thường. Một tin tặc có thể tạo ra nhiều truy cập đồng thời từ một máy để tấn công ứng dụng. Sử dụng load balancing sẽ gây khó khăn cho các cuộc tấn công kiểu này, tuy nhiên không thể ngăn ngừa hoàn toàn nếu có quá nhiều truy cập cùng lúc.  Một dạng khác của tấn công DoS ứng dụng web dựa trên các lỗi trong chức năng của ứng dụng. Ví dụ một ứng dụng sử dụng cơ chế khóa tài khoản trong 1 tiếng hoặc hơn nếu nhận được quá 3 lần mật khẩu sai. Hacker có thể lợi dụng điểm yếu này, gửi đến quá 3 lần sai mật khẩu của một tài khoản hợp lệ, hậu quả là người dùng của tài khoản này không thể truy cập được trong 1 tiếng hoặc hơn.  Trong một cuộc tấn công từ chối dịch vụ điển hình vào ứng dụng web, hackers sẽ tìm cách chiếm gần hết nguồn tài nguyên hệ thống trên máy chủ hoặc ứng dụng, hậu quả là người sử dụng hợp lệ không thể truy cập vào ứng dụng. Tài nguyên hệ thống bao gồm: băng thông, số lượng truy cập đồng thời cơ sở dữ liệu, dung lượng trống ổ cứng, CPU, dung lượng bộ nhớ RAM, threads, và các nguồn tài nguyên khác liên quan đến ứng dụng.  Hình 12 Tấn công từ chối dịch vụ Hình 12  mô tả một cuộc tấn công từ chối dịch vụ ứng dụng web điển hình. Trong tấn công này, hacker lợi dụng vào điểu yếu của ứng dụng cho phép truy cập đến cơ sở dữ liệu (CSDL) từ bất kỳ kết nối nào, ngay cả những truy cập không được xác thực. Giả định là ứng dụng chỉ có thể xử lý tối đa 1000 truy cập cùng lúc đến CSDL, hacker sẽ gửi đến ứng dụng hơn 1000 kết nối đồng thời, tạo ra hơn 1000 truy cập đến CSDL, hậu quả là ứng dụng bị tê liệt, không thể đáp ứng các truy cập hợp lệ từ người sử dụng. 2.1.10 Quản lý cấu hình thiếu an toàn Cấu hình của máy chủ và các phần mềm hỗ trợ dịch vụ web là một yếu tố quan trọng trong vấn đề bảo mật của ứng dụng. Máy chủ cung cấp nền tảng phục vụ cho việc cung cấp nội dung và các dịch vụ mà ứng dụng web cần sử dụng, bao gồm lưu trữ, dịch vụ directory, emai. Do là nền tảng cung cấp các chức năng cấp thấm cơ bản cho ứng dụng. Những vấn đề về cấu hình của máy chủ có thể dẫn đến vấn đề bảo mật của ứng dụng. Trong đại đa số các công ty, nhóm phát triển ứng dụng web thường tách biệt với nhóm hỗ trợ triển khai trang web trên máy chủ. Vì vậy, có sự không thống nhất và thiếu sự liên lạc về phương hướng bảo mật giữa hai nhóm này. Điều này có thể dẫn đến những điểm yếu nghiêm trọng trên ứng dụng được tạo ra từ các lỗ hổng ở máy chủ.  Theo các thống kê hiện nay, các lỗ hổng liên quan đến cấu hình máy chủ bao gồm:  Các phần mềm và hệ điều hành trên máy chủ không được cập nhật với bản vá lỗi bảo mật mới nhất.Lỗi trên phần mềm web hosting máy chủ cho phép liệt kê bất kỳ thư mục (hoặc tập tin) nào trong hệ thống. Những tập tin mặc định, tập tin tạo ra để test như script, tập tin cấu hình không được xóa đi trong thư mục của trang web. Những tập tin này thường có độ bảo mật yếu và có thể chứa những thông tin quan trọng. Không phân đúng quyền cho các thư mục và tập tin trong trang web. Những chức năng quản lý và debug được triển khai không cần thiết. Phần mềm web server đăng quá nhiều thông tin trong trang báo lỗi. Cấu hình SSL và các hàm mã hóa không đúng. 2.2 GIẢI PHÁP TOÀN DIỆN BẢO VỆ ỨNG DỤNG WEB Các lỗ hổng ứng dụng Web được đưa ra trong phần trên không phải là một vấn đề mới. Tuy nhiên do nhiều lý do, khá nhiều dự án phát triển phần mềm vẫn còn mắc phải những lỗ hổng này và đe dọa không chỉ đến độ an toàn cho khách hàng, mà còn ảnh hưởng chung đến an toàn của hệ thống Internet. Do tính chất phức tạp của ứng dụng, hiện nay không có một giải pháp tuyệt đối cho vấn đề này. Tuy nhiên nhằm giảm thiểu rui ro, các tổ chức lớn cần triển khai một giải pháp bảo vệ ứng dụng web một cách tông thể, bao gồm cả về con người, quy trình thủ tục và cả công nghệ. 2.2.1 Giải pháp về con người và quy trình thủ tục Các tiêu chí về bảo mật phải được đặt ra ngay từ lúc thiết kế ứng dụng nhằm phát triển các module bảo vệ ngay từ giai đoạn đầu của quá trình phát triển ứng dụng. Một văn bản chính thức thiết lập chính sách bảo mật ứng dụng nên được xây dựng nhằm cung cấp một chuẩn tối thiểu về bảo mật cho toàn ứng dụng. Thường xuyên cập nhật kiến thức bảo mật cho lập trình viên. 2.2.2 Giải pháp về công nghệ bảo vệ ứng dụng web Một hệ thống web với rất nhiều dữ liệu quý mang tính chất sống còn đối với tổ chức/doanh nghiệp, đồng thời thường xuyên diễn ra các giao dịch trực tuyến,… và đòi hỏi phải có độ an toàn, sẵn sàng cao. Cần triển khai hệ thống với nhiều lớp bảo mật khác nhau. Mô hình triển khai bảo mật có thể xây dựng dưới ba mức bảo mật như sau: Hình 13 Bảo vệ ứng dụng web toàn diện Mức 1: Thành phần tường lửa trong thiết bị sẽ ngăn chặn các tấn công tại mức mạng, các tấn công dò quét. Thành phần IPS ngăn chặn các tấn công khai thác điểm yếu của các hệ điều hành, điểm yếu của phần mềm web, phần mềm cơ sở dữ liệu. Thành phần VPN cho phép thiết lập kênh riêng ảo với các chi nhánh, phòng giao dịch và các người dùng từ xa Mức 2: Sử dụng thiết bị tường lửa chuyên dụng cho ứng dụng web nhằm kiểm soát mọi luồng dữ liệu đi đến mỗi máy chủ ứng dụng và thành phần Dynamic Application Protection (DAP) cho qua các yêu cầu hợp lệ và ngăn chặn mọi yêu cầu không hợp lệ. Các chính sách bảo mật được thiết lập cho từng phần của ứng dụng web với danh sách điều khiển truy cập web (Access Control Lists - ACL) có thể thiết lập luật cho từng trang web (URL), các tham số, thiết lập kiểm soát dữ liệu trên các trường của form nhập liệu và cho phép mã hoá các trường có thông tin quan trọng như trường nhập thông tin tài khoản, thông tin thẻ tín dụng,… Làm giảm các nguy cơ tấn công bằng cách che giấu toàn bộ tài nguyên của ứng dụng web đằng sau nó. Sau khi che giấu trang web, hệ thống tự động kiểm tra để đảm bảo ứng dụng hoạt động theo đúng ý đồ của người phát triển ứng dụng web Mức 3: có thể thiết lập thêm một mức bảo vệ thứ ba để phân tách mạng thành nhiều vùng mạng (zone) với các mức độ bảo mật khác nhau khi truy cập đến hệ thống máy chủ cơ sở dữ liệu và máy chủ ứng dụng web, chính sách trên có thể loại bỏ các tấn công vào ứng dụng trong trường hợp chúng vượt qua lớp bảo vệ thứ nhất và thứ hai hoặc các tấn công có nguồn gốc trong mạng.   2.2.3 Giải pháp bảo vệ cho ứng dụng web-hosting Đối với các ứng dụng web đặt trên nhà cung cấp internet, các giải pháp được đưa ra gồm: Dịch địa chỉ URL(Translate URL addresses) từ tên của DNS ngoài thành tên của DNS trong (Chuyển dịch địa chỉ Web - Web Address Translation) cho các giao dịch trên Web, tạo ra một địa chỉ khác cho người dùng truy cập đến thay vì truy cập thẳng vào địa chỉ thật nhằm che giấu cấu trúc của website. Tuỳ thuộc vào chính sách định ra mà có thể sửa lại cấu trúc đầu (Rewrite HTTP Header) của HTTP nhằm loại bỏ các thông tin không phù hợp chính sách hoặc các thông tin về hệ thống giúp khai thác điểm yếu của hệ thống. Kiểm tra URL theo danh sách điều khiển truy cập (Check URL ACLs) cho phép giới hạn truy cập vào một phần của website. Kiểm tra các tham số qua ACL (Check Parameter ACLs) cho phép loại bỏ các thông tin tấn công của Hacker khi lợi dụng các trang web cho phép đưa vào các thông tin như tên, địa chỉ,…việc kiểm tra này sẽ loại bỏ các đoạn mã virus, các lệnh của hệ điều hành, các đoạn mã nguy hiểm,…trong các ô thông tin này Kiểm tra các thông tin trong các mẫu nhập thông tin (Check Forms Tampering) như các ô nhập văn bản, ô lựa chọn (radio button) nhằm đảm bảo người dùng nhập đúng các thông tin yêu cầu và loại bỏ các mã tấn công được đưa vào máy chủ web qua đường này. Kiểm tra và loại bỏ các tấn công tràn vùng đệm (Check Field Buffer Overflow) Kiểm tra và loại bỏ các đoạn mã tấn công như SQL injection, Cross-Site Scripting,… (Check SQL/Script Injection). Che giấu các thông tin nhạy cảm của người dùng như thông tin về thẻ tín dụng và các thông tin nhạy cảm khác (Mask Credit Card numbers, and other sensitive data). Mã hoá và ký cho các thông tin Cookie (Encrypt or Sign Cookies) Hầu hết các máy chủ web đều cung cấp các thông tin về phiên bản của máy chủ web, phiên bản phần mềm,… trong code hoặc trên banner các hacker có thể dựa vào các thông tin này để tìm kiếm các điểm yếu của máy chủ web, các điểm yếu của phần mềm,…NetContinuum can thiệp và loại bỏ các thông tin này (Cloak all identifying banners and error codes). Nhận các yêu cầu và từ đó giới hạn các yêu cầu nhằm chống lại tấn công DoS (Queue Requests at Application Limits). Ngoài ra cần sử dụng dịch vụ đánh giá bảo mật của một công ty ngoài để kiểm tra tính bảo mật của ứng dụng, sử dụng các công cụ dò và phát hiện lỗi của ứng dụng ( công cụ Appscan đề cập trong chương IV là một ví dụ) ,cập nhật các phần mềm máy chủ web với các phiên bản vá lỗi bảo mật mới nhất. CHƯƠNG III MỘT SỐ TẤN CÔNG VÀO CÁC ĐIỂM YẾU QUAN TRỌNG VÀ GIẢI PHÁP BẢO VỆ 3.1. LỖI CROSS SITE SCRIPTING (XSS) 3.1.1 Mô tả việc khai thác Như phân tích ở chương II trong đồ án, điểm yếu XSS là một điểm yếu mà cho đến hiện nay đa số các website việt nam và thế giới chưa có một biện pháp triệt để để có thể ngăn chặn được từ các tấn công bên ngoài thông qua điểm yếu này. Về bản chất XSS là kĩ thuật tấn công bằng cách chèn vào các website động (ASP, PHP, CGI,...) các thẻ HTML hay những đoạn mã script nguy hiểm có thể gây nguy hại cho người sử dụng khác. Khi một trang web bị nhúng mã độc, những đoạn mã này sẽ được thực thi ở máy của người dùng gây tác hại cục bộ, hoặc có thể lấy các thông tin như cookie lưu ở trang web đó chuyển về cho tin tặc. Các đoạn mã này được thực thi với quyền của trang web nạn nhân, nên loại bỏ được một số kiểm soát truy cập (như chứng thực nguồn gốc). Em sẻ phân tích và là rõ hơn điểm yếu nguy hiểm này trong phần sau đây. Phương pháp  tấn công dựa vào XSS không nhằm vào máy chủ hệ thống mà chủ yếu tấn công trên chính máy người sử dụng. Hacker sẽ lợi dụng sự kiểm tra lỏng lẻo từ ứng dụng và hiểu biết hạn chế của người dùng cũng như biết đánh vào sự tò mò của họ dẫn đến người dùng bị mất thông tin một cách dễ dàng. Thông thường hacker lợi dụng địa chỉ URL để đưa ra những liên kết là tác nhân kích hoạt những đoạn chương trình được viết bằng ngôn ngữ máy khách như VBScript, JavaScript…được thực thi trên chính trình duyệt của nạn nhân.   alert (document.cookie); hay là: Phần in đậm là đoạn mã được thêm vào với mục đích đánh cắp cookies của nạn nhân. Trong những ví dụ  trên, hầu hết những  tiền tố URL là địa chỉ của những ứng dụng Web có thật (VD:  lợi dụng cách truyền tham số trên URL mà hacker có thể dễ dàng thêm vào đoạn mã đánh cắp cookie. Ví dụ  trên chỉ minh họa một cách đơn giản là thêm đoạn mã của mình vào trang Web  thông  qua  URL.  Nhưng  thực  sự  thì  có  rất  nhiều  cách  để  thêm  đoạn  mã JavaScript  với  mục  đích  tấn  công  kiểu  XSS.  Hacker  có  thể  dễ  dàng  lợi  dụng Document Object Model (DOM) để thay đổi ngữ cảnh và nội dụng Web ứng dụng. Sau đây là danh sách nơi có thể chèn đoạn mã: &[code] &{[code]}; [code]"> [code] [code] "  onmouseover="[code]"> <script>[code]</script>; 3.1.2 Phương pháp tấn công XSS truyền thống Ứng dụng Web thường lưu trữ thông tin quan trọng ở cookie. Cookie là mẩu thông tin mà ứng dụng lưu trên đĩa cứng của người sử dụng. Nhưng chỉ ứng dụng thiết lập ra cookie thì mới có thể đọc nó. Do đó chỉ khi người dùng đang trong phiên làm việc của ứng dụng thì hacker mới có cơ hội đánh cắp cookie. Công việc đầu tiên của hacker là tìm trang đích để dụ người dùng đăng nhập sau khi đã tìm ra lỗ hổng trên ứng dụng đó. Các bước thực hiện XSS truyền thống •   Bước 1: Hacker biết được người dùng đang sử dụng một ứng dụng Web có lỗ hỏng XSS. •   Bước 2: Người dùng nhận được 1 liên kết thông qua email hay trên chính trang Web (như trên guestbook, banner dễ dàng thêm 1 liên kết do chính hacker tạo ra…). Thông thường hacker khiến người dùng chú ý bằng những câu kích thích sự tò mò của người dùng như “ Kiểm tra tài khoản”, “Một phần thưởng hấp dẫn đang chờ bạn”… •   Bước 3: Chuyển nội dung thông tin (cookie, tên, mật khẩu…) về máy chủ của hacker. •   Bước 4: Hacker tạo một chương trình CGI (ở ví dụ 3 này là steal.cgi) hoặc một trang Web để ghi nhận những thông tin đã đánh cắp vào 1 tập tin •   Bước 5: Sau khi nhận được thông tin cần thiết, hacker có thể sử dụng để thâm nhập vào tài khoản của người dùng. 3.1.3 Tấn công bằng XSS Flash Ngoài những cách đưa một đoạn mã nguy hiểm thì hacker còn có thể lợi dụng những tập tin flash để đánh cắp thông tin. Macromedia Flash cho phép lập trình bằng một ngôn ngữ kịch bản đã được xây dụng sẵn trong Flash là ActionScript. ActionScript có cú pháp đơn giản và tương tự như JavaScript, C hay PERL. Ví dụ hàm getURL() dùng để gọi một trang web khác. 3.1.4 Tấn công chiếm phiên làm việc 3.1.4.1 Tổng quan về SessionID Như đã đề cập ở chương 2 của đồ án, Session dùng để lưu trữ trạng thái làm việc giữa trình duyệt và trình chủ. Session ID có thể được lưu trữ trong cookie hay được nhúng vào địa chỉ URL hay trong biến ẩn của form. Mỗi kiểu lưu trữ đều có ưu và khuyết điểm, nhưng qua thực tế cookie vẫn là lựa chọn tốt nhất, và là phương pháp an toàn nhất. Thông thường, sau khi người dùng được chứng thực dựa trên những thông tin cá nhân như tên/mật khẩu, session ID được xem như một mật khẩu tĩnh tạm thời cho những lần yêu cầu tiếp theo. Điều này đã khiến cho Session ID là mục tiêu lớn cho những hacker. Trong nhiều trường hợp, hacker giành được session ID hợp lệ của người dùng để từ đó đột nhập vào phiên làm việc của họ. Đây cũng là một loại tấn công XSS, nó còn được gọi là session hijacking Tấn công vào một phiên làm việc thường được thực hiện theo 2 kiểu chính sau: 3.1.4.2 Ấn định phiên làm việc Trong kiểu tấn công ấn định một phiên làm việc, hacker ấn định sẵn session ID cho nạn nhân trước khi họ đăng nhập vào hệ thống. Sau đó, hacker sẽ sử dụng session ID này để buớc vào phiên làm việc của nạn nhân đó. Tóm tắt quá trình tấn công: •   Bước 1: Thiết lập session ID. Hệ thống quản lí session theo 2 hướng: +  Hướng tự do: chấp nhận bất kì một session ID, nếu chưa tồn tại session   thì tạo mới một session ID + Hướng giới hạn: chỉ chấp nhận session ID nào đã đăng kí trước đó. Với hệ thống hướng tự do hacker chỉ cần thiết lập một session ID bất kì, nhớ và sau đó sử dụng lại session ID này. Ở hướng giới hạn, hacker phải đăng kí một session ID với ứng dụng. Phụ thuộc vào qui trình quản lí phiên làm việc mà hacker lưu trữ thời gian sống của phiên làm việc cho đến khi nạn nhân đăng nhập vào hệ thống. Thông thường một phiên làm việc không tồn tại vô hạn định.   Hệ thống sẽ tự động hủy bỏ phiên làm việc nếu nó không thực hiện một thao tác nào (thời gian nhàn rỗi ) hoặc hết hạn định. Do đó bước  kẻ tấn công sẽ bảo trì phiên làm việc bằng cách gửi yêu cầu đến server. •   Bước 2: Gởi ID này đến trình duyệt nạn nhân. Hacker gửi session ID vừa tạo đến người dùng và việc trao đổi ID session còn tùy vào ứng dụng mà có thể qua URL, biến ẩn form hay cookie. Các cách tấn công thông dụng gồm: Tấn công session ID trên tham số URL. Tấn công session ID bằng biến ẩn form. Tấn công session ID trong cookie. •   Bước 3: Đột nhập vào phiên làm việc của nạn nhân. Sau khi nạn nhân đăng nhập vào hệ thống qua session ID đã được chỉ định sẵn và chưa thoát khỏi ứng dụng, hacker lúc này bắt đầu dùng session ID đó để bước vào phiên làm việc của nạn nhân. 3.1.4.3  Đánh cắp phiên làm việc Hacker gửi một liên kết yêu cầu người dùng đăng nhập vào hệ thống máy đích với sessionID đã được ấn định sẵn trên URL. Hacker  mở  dịch  vụ  trực  tuyến  của  ngân  hàng  thông  qua  địa  chỉ: Nhận được một session ID từ trình chủ để xác định phiên làm việc của hacker. Ví dụ session ID có giá trị là 1234. Sau đó hacker sẽ tìm cách gửi một liên kết đến một người dùng nào đó có tài khoản trong ngân hàng này. Những liên kết đó thường là dẫn đến trang đăng nhập   vào   tài   khoản   trong   ngân   hàng . ví dụ liên kết là để lừa người dùng làm việc trong phiên làm việc của hackerkhi người dùng nhận được liên kết này, Người dùng bị mắc lừa và mở ứng dụng Web bằng liên kết của hacker. Do đã có session ID (của hacker) nên trình chủ sẽ không tạo một session ID  mới. Người dùng vẫn tiếp tục đăng nhập với thông tin của mình để quản lý tài khoản. Khi đó hacker sẽ vào tài khoản của người dùng mà không cần phải đăng nhập vì có cùng phiên làm việc. 3.1.4.4 Tấn công Session ID trên tham số URL Hacker gửi một liên kết yêu cầu người dùng đăng nhập vào hệ thống máy đích với sessionID đã được ấn định sẵn trên URL. Ví dụ:   Hình 13- Tấn công Sessionid trên tham số URL 1.  Hacker  mở  dịch  vụ  trực  tuyến  của  ngân  hàng  thông  qua  địa  chỉ online.worldbank.com 2.   Nhận được một session ID từ trình chủ để xác định phiên làm việc của hacker. Ví dụ session ID có giá trị là 1234. 3.  Sau đó hacker sẽ tìm cách gửi một liên kết đến một người dùng nào đó có tài khoản trong ngân hàng này. Những liên kết đó thường là dẫn đến trang đăng nhập vào tài khoản trong ngân hàng ví dụ liên kết         là:  để lừa người dùng làm việc trong phiên làm việc của hacker khi người dùng nhận được liên kết này, 4.  Người dùng bị mắc lừa và mở ứng dụng Web bằng liên kết của hacker. Do đã có session ID (của hacker) nên trình chủ sẽ không tạo một session ID  mới. 5.  Người dùng vẫn tiếp tục đăng nhập với thông tin của mình để quản lý tài khoản. 6.  Khi đó hacker sẽ vào tài khoản của người dùng mà không cần phải đăng nhậpvì có cùng phiên làm việc. 3.1.5 Phòng chống Với những dữ liệu, thông tin nhập của người dùng, người thiết kế ứng dụng Web cần phải thực hiện vài bước cơ bản sau: Tạo ra danh sách những thẻ HTML được phép sử dụng. Xóa bỏ thẻ 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 Lọc kí tự Null ( vì khả năng thêm một đoạn mã bất kì sau kí tự Null  khiến cho ứng dụng dù đã lọc bỏ thẻ vẫn không nhận ra do ứng dụng nghĩ rằng chuỗi đã kết thúc từ kí tự Null này). 3.2 LỖI INJECTION 3.2.1. Khái niệm SQL Injection Một điểm yếu nghiêm trọng nữa là điểm yếu về việc kiểm tra dữ liệu đầu vào(data  input) injection Đây là lỗ hổng trong việc kiểm tra dữ liệu nhập trong các ứng dụng web và các thông báo lỗi của hệ quản trị cơ sở dữ liệu là cho hacker có thể "tiêm vào" (inject) và thi hành các câu lệnh SQL bất hợp pháp (không được người phát triển ứng dụng lường trước). Hậu quả của nó rất tai hại vì nó cho phép những kẻ tấn công có thể thực hiện các thao tác xóa, hiệu chỉnh, … do có toàn quyền trên cơ sở dữ liệu của ứng dụng, thậm chí là server mà ứng dụng đó đang chạy.Đây không chỉ là khuyết điểm của riêng SQL Server mà nó còn là vấn đề chung cho toàn bộ các cơ sở dữ liệu khác như Oracle, MS Access. Khi hacker gửi những dữ liệu (thông qua các form), ứng dụng Web sẽ thực hiện và trả về cho trình duyệt kết quả câu truy vấn hay những thông báo lỗi có liên quan đến cơ sở dữ liệu. Và nhờ những thông tin này mà hacker biết được nội dung cơ sở dữ liệu và từ đó có thể điều khiển toàn bộ hệ thống ứng dụng. Hầu hết các lỗi SQL Injection đều là do câu lệnh SQL sai hoặc do User làm cho câu lệnh SQL sai , không thực hiện đúng chức năng của nó . 3.2.2. Giới thiệu mô hình cơ sở dữ liệu Để trình bày tốt hơn nội dung kĩ thuật này, đồ án sử dụng bảng User để minh họa kĩ thuật tấn công. Bảng User: STT Tên trường Cài đặt vật lý Kiểu trường Kích thước Diễn giải 1 tkUsername Khoá chính Text 50 Mỗi người dùng có 1 account để đăng nhập 2 tkPassword Text 50 Pass để đăng nhập Quy ước: Ngôn ngữ lập trình sử dụng để minh họa trong chương này là ASP với cơ sở dữ liệu là SQL Server. 3.2.3 Kỹ thuật tấn công cơ bản 3.2.3.1 Sử dụng ký tự đặc biệt 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ụ 1. giả sử ứng dụng web có đoạn mã sau: SQLQuery= “SELECT tkUsername FROM User WHERE tkUsername= ‘” & strUsername & “’ AND Password= ‘” & tkPassword & “’” flag= GetQueryResult (SQLQuery) if flag = “” then check=FALSE else check=TRUE end if Đoạn mã trên kiểm tra chuỗi nhập Username và Password. Nếu tồn tại trong bảng User thì check=true ngược lại check=false. Nếu kẻ tấn công nhập vào giá trị là: Username: ’ OR ‘’=’ Password: ’ OR ‘’=’ Câu lệnh SQL lúc này như sau: SELECT tkUsername FROM User WHERE tkUsername= ‘’ OR ‘’=’‘ AND Password= ‘’ OR ‘’=’’ Câu lệnh so sánh trên luôn luôn đúng (vì ‘’ luôn bằng ‘’). Do đó câu điều kiện trong mệnh đề WHERE luôn đúng. Giá trị tên người sử dụng của dòng đầu tiên trong bảng sẽ được chọn. 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ụ 2. Gía trị nhập vào : Username: ’; drop table User-- Password: Câu lệnh SQL lúc này như sau: SELECT tkUsername FROM User WHERE tkUsername= ‘’;drop table User-- AND Password= ‘” & tkPassword & “’” Với câu lệnh trên thì bảng User sẽ bị xóa hoàn toàn. Ví dụ 3. Một ví dụ khác sử dụng kí tự đặc biệt SQL để thâm nhập vào hệ thống như sau: Username: admin’-- Password: Câu lệnh SQL như sau: SELECT tkUsername FROM User WHERE tkUsername= ‘admin’—AND Password= ‘” & tkPassword & “’” Câu lệnh trên cho phép đăng nhập vào hệ thống với quyền admin mà không đòi hỏi password. 3.2.3.2. Tấn công dưa vào câu lệnh SELECT Ngoài kĩ thuật đơn giản trên, việc tấn công thường dựa trên những thông báo lỗi để lấy thông tin về bảng cũng như những trường trong bảng. Để làm được điều này, cần phải hiểu những thông báo lỗi và từ đó chỉnh sửa nội dung nhập cho phù hợp. Khái niệm Direct Injection: Những đối số được thêm vào trong câu lệnh mà không nằm giữa những dấu nhấy đơn hay dấu ngoặc kép là trường hợp direct injection. Ví dụ 4: StrSQL=“SELECT tkUsername FROM User WHERE tkUsername=”& tName Khái niệm Quote Injection: Những trường hợp đối số được nhập vào đều được ứng dụng cho vào giữa hai dấu nháy đơn hay ngoặc kép là trường hợp Quote Injection Ví dụ 5: StrSQL=“SELECT tkUsername FROM User WHERE tkUsername=’”& tName &“’” Để vô hiệu hoá dấu nháy và thay đổi câu lệnh mà vẫn giữ được cú pháp đúng, chuỗi mã chèn thêm vào phải có một dấu nháy đơn trước chuỗi kí tự được chèn vào và ở cuối câu lệnh phải có một dấu nháy đơn, chẳng hạn như sau: StrSQL=“SELECT tkUsername FROM User WHERE tkUsername=’’ and ‘’=’’” Nếu đã thực hiện như trên mà thông báo lỗi có liên quan đến dấu “(“ thì trong chuỗi chèn vào phải có “)”: 3.2.3.3 Tấn công dựa vào câu lệnh HAVING HAVING sử dụng cùng chung với mệnh đề GROUP BY là phương pháp hữu hiệu để nhận thông tin bảng, trường. Microsoft SQL phát triển riêng cho mình 1 cách viết lệnh SQL mới , còn gọi là Transact SQL, hay TSQL. Em  sẽ sử dụng sức mạnh của TSQL để mô tả về cách thức tấn công SQL Injection. Hãy dựa vào câu SQL mà chúng ta đang xem xét. Giả sử em nhập vào : Username: ' having 1=1 ---  Password: [Anything]  Câu SQL trở thành select userName from users where userName='' having 1=1 Và ngay lập tức , Ms.SQL báo lỗi và gửi trả về màn hình trang web: Microsoft OLE DB Provider for SQL Server (0x80040E14) Column 'users.userName' is invalid in the select list because it is not contained in an aggregate function and there is no GROUP BY clause. /login.asp, line 16  Nhìn kỹ lại thông báo và chúng ta thấy rằng Ms.SQL đã để lộ 2 thông tin cho người dùng vô danh (ở đây là chúng ta đang thử khai thác lỗi SQL Injection) là tên của 1 Field và tên của Table mà chúng ta đang muốn xâm nhập , field "users.userName" . Sử dụng tên có được này chúng ta dùng cú pháp LIKE : Username: ' or users.userName like 'a%' --- Password: [Anything] và câu SQL trở thành select userName from users where userName='' or users.userName like 'a%' --' and userPass='' Câu SQL này thu thập tất cả những users có Username bắt đầu là "a" và trong trường hợp này là admin Logge