intTypePromotion=1

KHÁI NIỆM ỨNG DỤNG WEB

Chia sẻ: Pham Việt Hưng | Ngày: | Loại File: DOC | Số trang:6

0
223
lượt xem
59
download

KHÁI NIỆM ỨNG DỤNG WEB

Mô tả tài liệu
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

Hình bên dưới minh họa chi tiết mô hình ứng dụng Web ba tầng. Tầng đầu tiên thông thường là trình duyệt Web hoặc giao diện người dùng. Tầng thứ hai là công nghệ kỹ thuật tạo nội dung động như Java servlets (JSP) hay Active Server Pages (ASP). Còn tầng thứ ba là cơ sở dữ liệu chứa nội dung (như tin tức) và dữ liệu người dùng (như username, password, mã số bảo mật xã hội, chi tiết thẻ tín dụng)....

Chủ đề:
Lưu

Nội dung Text: KHÁI NIỆM ỨNG DỤNG WEB

  1. . KHÁI NIỆM ỨNG DỤNG WEB Định nghĩa Phuong thức hoạt động :D Hình bên dưới minh họa chi tiết mô hình ứng dụng Web ba tầng. Tầng đầu tiên thông thường là trình duyệt Web hoặc giao diện người dùng. Tầng thứ hai là công nghệ k ỹ thuật tạo n ội dung động như Java servlets (JSP) hay Active Server Pages (ASP). Còn t ầng thứ ba là cơ s ở dữ liệu ch ứa n ội dung (như tin tức) và dữ liệu người dùng (như username, password, mã số bảo m ật xã h ội, chi tiết thẻ tín dụng). Hình 1 Quá trình hoạt động bắt đầu với yêu cầu được tạo ra từ người dùng trên trình duyệt, gửi qua Internet tới trình chủ Web ứng dụng (Web application Server). Web ứng dụng truy cập máy ch ủ ch ứa c ơ s ở d ữ liệu để thực hiện nhiệm vụ được yêu cầu: cập nhật, truy vấn thông tin đang nằm trong cơ s ở dữ liệu. Sau đó ứng dụng Web gửi thông tin lại cho người dùng qua trình duyệt.
  2. Hình 2 Các vấn đề bảo mật Web Mặc dù không thể phủ nhận những cải tiến nâng cao đáng kể hiện nay, nhưng vấn đề về b ảo m ật trong ứng dụng Web vẫn không ngừng tăng lên. Nguyên nhân có thể xuất phát t ừ các đo ạn mã không phù hợp. Nhiều điểm yếu nghiêm trọng hay các lỗ hổng cho phép hacker xâm nhập thẳng và truy cập vào cơ sở dữ liệu tách lấy dữ liệu nhạy cảm. Nhiều cơ sở dữ liệu chứa thông tin giá trị (như chi tiết cá nhân, thông tin tài chính) khiến chúng trở thành đích nhắm thường xuyên của hầu hết hacker. M ặc dù hoạt động tấn công phá hoại website doanh nghiệp vẫn diễn ra thường xuyên, nhưng bây giờ tin tặc thích tăng cường khả năng truy cập dữ liệu nhạy cảm nằm trên trình chủ chứa database h ơn vì l ợi nhuận khổng lồ từ các vụ mua bán dữ liệu đem lại. Trong khung hoạt động mô tả ở trên, bạn có thể thấy thật dễ dàng cho một hacker truy cập nhanh chóng thông tin nằm trên cơ sở dữ liệu chỉ với một chút sáng tạo. Nếu may mắn hơn chúng có th ể g ặp lỗ hổng xuất phát từ sự cẩu thả hay lỗi người dùng trên các ứng dụng Web. Như đã nói, website phụ thuộc vào cơ sở dữ liệu để phân phối thông tin được yêu cầu cho ng ười dùng. Nếu ứng dụng Web không an toàn (như có lỗ hổng, gặp phải một kiểu kỹ thuật hacking nào đó), toàn bộ cơ sở dữ liệu chứa thông tin nhạy cảm sẽ gặp nguy hiểm nghiệm trọng. Một số hacker có thể chèn mã độc hại vào ứng dụng Web có lỗ hổng để lừa đảo người dùng và d ẫn họ tới website phishing. Kỹ thuật này được gọi là Cross-site Scripting, có thể đ ược dùng ngay cả khi bản thân Web Server và nơi chứa cơ sở dữ liệu không có lỗ hổng nào.
  3. Một cuộc nghiên cứu gần đây chỉ ra rằng 75% các cuộc tấn công mạng được thực hiện ở mức ứng dụng Web. Hình 3 • Website và các ứng dụng Web liên quan luôn phải sẵn sàng 24/7 để cung cấp d ịch v ụ theo yêu c ầu khách hàng, yêu cầu từ phía nhân viên, nhà cung cấp và nhiều người liên quan khác. • Tường lửa, SSL không thể bảo vệ ứng dụng Web trước mọi hoạt động hacking, đơn giản vì truy cập vào website phải để ở chế độ public để bất kỳ ai cũng có thể ghé thăm website được. Tất cả h ệ thống cơ sở dữ liệu hiện đại (như Microsoft SQL Server, Oracle, MySQL) đều có thể truy cập qua một số cổng cụ thể (như cổng 80, 443). Nếu muốn, một người nào đó có thể kết nối trực tiếp t ới cơ sở dữ liệu một cách hiệu quả khi vượt qua cơ chế bảo mật của hệ điều hành. Các cổng này để m ở nhằm cho phép liên lạc với hoạt động giao thông mạng hợp pháp, và do đó cũng hình thành nên lỗ hổng lớn nguy hiểm. • Các ứng dụng Web thường truy cập dữ liệu cuối như cơ sở dữ liệu khách hàng, điều khiển d ữ liệu có giá trị và do đó rất khó để có thể tuyệt đối an toàn. Lúc này truy cập d ữ liệu th ường không kèm script cho phép đóng gói và truyền tải dữ liệu. Nếu một hacker nhận ra điểm yếu trong m ột script, anh ta có thể dễ dàng mở lại lưu lượng sang khu vực khác và chia lẻ bất hợp pháp chi tiết cá nhân người dùng, dù đôi khi không hề chủ tâm làm điều đó • Hầu hết ứng dụng Web đều là tự tạo, do đó ít có được các kiểm tra trình độ hơn so v ới ph ần mềm cùng loại. Do đó các ứng dụng tùy biến thường dễ bị tấn công hơn.
  4. Có thể nói ứng dụng Web là một cổng vào (gateway) của cơ sở dữ liệu, nhất là các ứng dụng tùy biến. Chúng không được phát triển với mức bảo mật tốt nhất vì không phải qua các kiểm tra b ảo m ật thông thường. Nói chung, bạn cần trả lời câu hỏi: “Phần nào trên website chúng ta nghĩ là an toàn nhưng lại mở cửa cho các cuộc tấn công?” và “Dữ liệu nào chúng ta đem vào m ột ứng dụng khiến nó thực hiện một số điều không nên làm?”. Đó là công việc của phần mềm rà soát lỗ hổng Web. Các kĩ thuật tấn công về ứng dụng web Những nguy cơ của những cuộc tấn công từ ứng dụng web. Tổng kết Cách phòng chống. +Đối với nhà quản trị mạng +Voi nha thiet ke ung dung web +Voi nguoi su dung ung dung web Công cụ bảo mật ứng dụng web. Chương trình web checker Những vấn để đạt được và hạn chế. Trong hầu hết trình duyệt, những kí tự nên được mã hoá trên địa chỉ URL trước khi được sử dụng. Việc tấn công theo SQL Injection dựa vào những câu thông báo lỗi do đó việc phòng chống hay nhất vẫn là không cho hiển thị những thông điệp lỗi cho người dùng bằng cách thay thế những lỗi thông báo bằng 1 trang do người phát triển thiết kế mỗi khi lỗi xảy ra trên ứng dụng. Kiểm tra kĩ giá trị nhập vào của người dùng, thay thế những kí tự như ‘ ; v..v.. Hãy loại bỏ các kí tự meta như “',",/,\,;“ và các kí tự extend như NULL, CR, LF, ... trong các string nhận được từ: dữ liệu nhập do người dùng đệ trình - các tham số từ URL - các giá trị từ cookie -
  5. Đối với các giá trị numeric, hãy chuyển nó sang integer trước khi thực hiện câu truy vấn SQL, hoặc dùng ISNUMERIC để chắc chắn nó là một số integer. Dùng thuật toán để mã hoá dữ liệu Kiểm tra dữ liệu Kiểm tra tính đúng đắn của dữ liệu là 1 vấn đề phức tạp và thường chưa được quan tâm đúng mức trong các ứng dụng. Khuynh hướng của việc kiểm tra tính đúng đắn của dữ liệu không phải là chỉ cần thêm một số chức năng vào ứng dụng, mà phải kiểm tra một cách tổng quát nhanh chóng để đạt được mục đích. Những tóm tắt sau đây sẽ bàn về việc kiểm tra tính đúng đắn của dữ liệu, cùng với ví dụ mẫu để minh hoạ cho vấn đề này. Có ba giải pháp tiếp cận vấn đề này: 1) Cố gắng kiểm tra và chỉnh sửa để làm cho dữ liệu hợp lệ. 2) Loại bỏ những dữ liệu bất hợp lệ. 3) Chỉ chấp nhận những dữ liệu hợp lệ Khóa chặt SQL server : Đây là một danh sách các công việc cần làm để bảo vệ SQL server: Xác định các phương pháp kết nối đến server: Dùng tiện ích Network Utility để kiểm tra rằng chỉ có các thư viện m ạng đang dùng là hoat động. Kiểm tra tất cả các tài khoản có trong SQL Server Chỉ tạo tài khoản có quyền thấp cho các ứng dụng Loại bỏ những tài khoản không cần thiết - Đảm bảo rằng tất cả tài khoản có một mật khẩu hợp lệ, … - Kiểm tra các đối tượng tồn tại
  6. Nhiều extended stored procedure có thể được xoá bỏ một cách an toàn. Nếu điều này được thực hiện, thì cũng nên xem xét việc loại bỏ luôn những t ập tin .dll ch ứa mã của các extended stored procedure Xoá bỏ tất cả cơ sở dữ liệu mẫu như “northwind” và “pubs” Xóa các stored procedure không dùng như: master..xp_cmdshell, xp_startmail, xp_sendmail, sp_makewebtask Kiểm tra những tài khoản nào có thể truy xuất đến những đối tượng nào Đối với những tài khoản của một ứng dụng nào đó dùng để truy xuất cơ sở dữ liệu thì chỉ được cấp những quyền hạn cần thiết tối thiểu để truy xuất đến những đối tượng nó cần dùng. Kiểm tra lớp sửa chữa của server Có một số cách tấn công như “buffer overflow”, “format string” thường chú ý đ ến lớp b ảo vệ này. Kiểm tra các phiên làm việc trên server. Thay đổi "Startup và chạy SQL Server" ở mức người dùng quyền hạn thấp trong SQL Server Security. Xữ lí khi bị tràn bộ đệm: Người thiết kế Web cần phải kiểm tra kĩ kích thước dữ liệu trước khi sử dụng. Dùng Referer trong HTTP Header để kiểm tra yêu cầu có ph ải xu ất phát t ừ máy người dùng. .
ADSENSE
ADSENSE

CÓ THỂ BẠN MUỐN DOWNLOAD

 

Đồng bộ tài khoản
2=>2