Vấn đề bảo mật trong ứng dụng Ajax
AJAX, viết tắt từ Asynchronous JavaScript and XML (JavaScript và XML không đồng bộ), là
bộ công cụ cho phép tăng tốc độ ứng dụng web bằng cách cắt nhỏ dữ liệu và chỉ hiển thị
những gì cần thiết, thay vì tải đi tải lại toàn bộ trang web.
Vấn đề bảo mật trong ứng dụng Ajax
AJAX là gì?
AJAX, viết tắt từ Asynchronous JavaScript and XML (JavaScript và XML không đồng bộ), là
bộ công cụ cho phép tăng tốc độ ứng dụng web bằng cách cắt nhỏ dữ liệu và chỉ hiển thị
những gì cần thiết, thay vì tải đi tải lại toàn bộ trang web. AJAX không phải một công nghệ
đơn lẻ mà là sự kết hợp một nhóm công nghệ với nhau. Trong đó, HTML và CSS đóng vai
hiển thị dữ liệu, mô hình DOM trình bày thông tin động, đối tượng XMLHttpRequest trao đổi
dữ liệu không đồng bộ với máy chủ web, còn XML là định dạng chủ yếu cho dữ liệu truyền.
Đây đều là công nghệ sẵn có nhưng Javacript đã lắp ráp chúng lại để thực hiện nhanh hơn,
tốt hơn các yêu cầu của người sử dụng
AJAX được cải tiến như thế nào so với các ứng dụng Web truyền thống?
Đối với ứng dụng Web truyền thống, hoạt động của người sử dụng trên trang web sẽ tạo ra
một yêu cầu HTTP tới máy chủ. Máy chủ thực hiện một số khâu xử lý như lấy lại dữ liệu,
tính toán, kiểm tra sự hợp lệ của thông tin, sửa đổi bộ nhớ, sau đó gửi lại một trang HTML
hoàn chỉnh tới máy khách. Về mặt kỹ thuật, phương pháp này cũng khá bất tiện và mất thời
gian, bởi khi máy chủ đang thực hiện nhiệm vụ của nó thì người dùng chỉ có một việc là chờ
đợi.
Để khắc phục hạn chế trên, các chuyên gia phát triển giới thiệu hình thức trung gian - cơ chế
xử lý AJAX (AJAX Engine) - giữa máy khách và máy chủ. Điều này giống như việc tăng thêm
một lớp giữa cho ứng dụng để giảm quá trình đi lại của thông tin và giảm thời gian phản
ứng. Mọi thao tác của người sử dụng sẽ gửi lệnh JavaScript tới bộ xử lý AJAX, thay vì tạo ra
một yêu cầu HTTP (HTTP request) và truy vấn tới máy chủ. Thay vì tải lại (refresh) toàn bộ
một trang, nó chỉ nạp những thông tin được thay đổi, còn giữ nguyên các phần khác.
Những vấn đề bảo mật gì tồn tại trong ứng dụng AJAX?
Trong khi AJAX có thể tăng khả năng sử dụng ứng dụng Web với các ưu điểm của mình, nó
cũng đồng thời tạo ra nhiều vấn đề về bảo mật ở cả hai phía máy khách (client) và máy chủ
(server):
• Tạo nên một diện tấn công lớn hơn trước với nhiều dữ liệu vào (input) cần bảo vệ
• Phơi bày những chức năng ở bên trong của ứng dụng Web
• Cho phép các kịch bản (script) phía máy khách truy xuất đến tài nguyên của bên thứ ba.
Điều này rất nguy hiểm nếu như không xây dựng một cơ chế bảo mật tốt.
Tăng khả năng bị tấn công
Trong khi ứng dụng Web truyền thống được chứa toàn bộ trên máy chủ thì ứng dụng AJAX
được mở rộng qua cả hai phía máy khách và máy chủ. Việc này đòi hỏi phải bổ sung một mối
quan hệ tin cậy giữa máy khách và máy chủ. Và mối quan hệ này có thể bị khai thác bởi kẻ
tấn công.
Nếu ví một ứng dụng Web truyền thống như là một ngôi nhà chỉ có hai cửa ra vào và không có
cửa sổ thì chỉ có hai cách để đi vào nó: bằng cổng trước và bằng cổng sau. Tuy nhiên, trong
một ứng dụng AJAX, có rất nhiều yêu cầu được gửi đi và sẽ tạo nên rất nhiều input vào ứng
dụng. Những input này, còn được gọi là AJAX endpoints, cung cấp nhiều cách cho kẻ tấn
công xâm nhập ứng dụng cũng như một ngôi nhà dù có khóa hai cửa chính thì vẫn còn rất
nhiều cửa sổ không được bảo vệ.
Rò rỉ thông tin
JavaScript trong AJAX nhận yêu cầu của người dùng và thực hiện chức năng gọi đến máy
chủ dưới dạng dữ liệu văn bản (cleartext). Ví dụ như:
• Trả về giá của sản phẩm có ID là 24
• Trả về các thành phố chính xác của bang được yêu cầu
• Trả về địa chỉ chính xác gần nhất của người dùng có ID là 78
• Cập nhật tuổi của người dùng trong cơ sở dữ liệu
Những thông tin này được gửi đi dưới dạng cleartext, và hoàn toàn có thể bị khai thác bởi kẻ
tấn công. Từ những thông tin này, kẻ tấn công có thể biết được tên hàm, tên biến, các thông
số của hàm, kiểu trả về, kiểu dữ liệu và phạm vi chính xác của dữ liệu.
Kẻ tấn công xuất hiện trong ứng dụng AJAX
Từ chối yêu cầu và lỗi Cross-Site Scripting (XSS)
Trình duyệt yêu cầu và cơ chế xử lí AJAX gửi đến máy chủ một yêu cầu y hệt. Máy chủ
không có khả năng nhận thức rõ ràng rằng yêu cầu là một JavaScipt và sẽ trở nên rất khó để
xác định xem chúng có phải là một hành vi đúng đắn hay không.
Điều này cũng có nghĩa là JavaScript có thể thực hiện các yêu cầu cho tài nguyên sử dụng
AJAX mà người dùng không nhận thức được. Trình duyệt sẽ tự động thêm những xác thực
cần thiết hoặc giữ trạng thái của thông tin như cookie. Mã JavaScript có thể truy xuất đến đáp
ứng của yêu cầu ẩn này và sau đó gửi đi nhiều yêu cầu hơn. Chính sự mở rộng này làm tăng
khả năng bị tấn công XSS.
Với AJAX, XSS có thể tạo nên các yêu cầu nguy hiểm đối với người dùng mà không cần tải
lại trang Web. Những Script độc hại có thể bí mật đọc nội dung của trang Web mà người
dùng đang xem. Sử dụng AJAX, một tấn công XSS có thể gửi nhiều yêu cầu cho những trang
đặc biệt bên cạnh những trang mà người dùng đang xem.
Với ứng dụng Web truyền thống, việc tiêm và phát tán XSS được thực hiện bởi một kẻ tấn
công thường là trên một phần duy nhất của Website. Với ứng dụng AJAX, XSS có thể được
phát tán như một virus. XSS có thể sử dụng yêu cầu AJAX để tự tiêm bản thân nó vào trong
trang và dễ dàng tiêm lại vào các máy (host) khác với nhiều XSS hơn vì không cần phải tải
lại. XSS có thể gửi nhiều yêu cầu sử dụng những phương thức HTTP phức tạp để truyền
đến người dùng một cách vô hình.
Vào tháng 10 năm 2005, một thành viên của mạng xã hội MySpace.com đã tạo một hồ sơ
(profile) cá nhân có chứa một loại sâu tự động phát tán, sâu Samy, đánh dấu trường hợp tấn
công đầu tiên lợi dụng XSS trong AJAX. Khi profile được xem bởi người khác, đo ạn mã tự
động thêm người này vào danh sách “bạn bè” của Samy đồng thời được sao chép đến profile
của nạn nhân.
Tháng 6 năm 2006, sâu Yamanner ảnh hưởng đến người dùng dịch vụ web mail của Yahoo
(một dịch vụ webmail được dùng rất phổ biến). Sâu này sử dụng XSS và AJAX, khi một
email bị nhiễm độc được mở, đoạn mã viết bằng JavaScript sẽ được thực hiện và gửi một
bản sao của chính nó đến tất cả các địa chỉ trong sổ địa chỉ của nạn nhân.
Cầu nối AJAX (AJAX Bridging)
Vì mục đích bảo mật, ứng dụng AJAX chỉ có thể kết nối ngược lại với website kết nối đến
nó. Ví dụ, JavaScript với AJAX được tải về từ yahoo.com không thể tạo kết nối đến
google.com. Để cho phép AJAX liên hệ với site của bên thứ ba, một dịch vụ cầu nối AJAX
được thiết lập. Trong một cầu, một host cung cấp một dịch vụ web đóng vai trò như một
trung gian (proxy) để chuyển tiếp lưu lượng giữa JavaScript đang chạy trên máy khách và site
của bên thứ ba. Một cầu có thể được xem như là một kết nối “Dịch vụ web đến dịch vụ
web”. Rất nhiều kiểu khung web như là Microsoft Atlas, cung cấp hỗ trợ cho cầu AJAX. Các
giải pháp khác như PHP hay chương trình CGI cũng cung cấp cầu AJAX.
Một cầu AJAX có thể kết nối bất cứ dịch vụ web nào trên bất cứ host nào sử dụng giao thức
như là SOAP (Simple Object Access Protocol) hay REST (Representational State
Transfer). Cầu cũng có thể kết nối đến các đối tượng khác như RSS, HTML, Flash.
Vấn đề bảo mật của cầu nối
Cầu nối trong AJAX làm phát sinh một số vấn đề bảo mật. Ví dụ một ứng dụng AJAX cho
phép lưu trữ sách online gọi là spibooks.com muốn truy cập đến một vài dịch vụ Web mà
majorbookstore.com cung cấp như là tìm tên tác giả. Để làm điều này, spibooks.com gửi mã
JavaScript qua cầu nối AJAX đến majorbookstore.com. Mặc dù bất cứ người nào cũng có thể
đăng ký một tài khoản miễn phí (free account) để truy cập vào dịch vụ Web của
majorbookstore.com, nhưng các tài khoản này có quyền rất giới hạn và được thiết lập khá
chậm. Trong khi một sự thỏa thuận giữa hai công ty cho phép spibooks.com có thể truy cập
đến majorbookstore.com ít bị hạn chế hơn.
Trong trường hợp này, một kẻ tấn công muốn copy toàn bộ cơ sở dữ liệu về các tác giả từ
majorbookstore.com có thể thực hiện bằng cách phát ra hàng ngàn truy vấn đến cầu nối AJAX
đang chạy trên spibooks.com. Do số lượng yêu cầu lớn, majorbookstore.com có thể thực hiện
lưu cache các yêu cầu này để làm giảm băng thông mạng. Mối quan hệ giữa hai Website cho
phép kẻ tấn công thu thập được nhiều thông tin hơn là dùng một tài khoản miễn phí trên trang
majorbookstore.com.
Kẻ tấn công có thể gửi một yêu cầu nguy hiểm từ spibooks.com đến majorbookstore.com.
Tuy nhiên các giao dịch bình thường có thể bị ngăn cản nếu một hệ thống chống xâm nhập
(IPS) tại majorbookstore.com phát hiện ra yêu cầu nguy hiểm đến từ địa chỉ IP của
spibooks.com và sau đó tự động block tất cả yêu cầu đến từ site này. Trong trường hợp này,
thay vì thực hiện các tấn công XSS đến majorbookstore.com, kẻ tấn công coi như đã thực
hiện tấn công từ chối dịch vụ (DoS) chống lại người dùng của spibooks.com!
Cũng có khả năng majorbookstore.com không phát hiện được tấn công qua cầu AJAX vì nó
không kiểm tra kỹ yêu cầu nó nhận được từ spibooks.com như khi nó nhận được các yêu cầu
từ các nguồn khác do đã có thỏa thuận từ trước.
Các khuyến cáo được đưa ra khi xây dựng một ứng dụng Ajax là gì?
Khi có ý định thay đổi các ứng dụng doanh nghiệp sang nền ứng dụng Web, cần chú ý đến
những câu hỏi sau:
• Có nên chuyển đổi các ứng dụng thông thường sang ứng dụng Web?
• Có nên chuyển đổi các ứng dụng Web truyền thống sang ứng dụng AJAX?
• Điều gì sẽ được cải tiến khi thực hiện chuyển đổi?
Nếu quyết định phát triển ứng dụng Web, truyền thống hoặc AJAX, nên chú ý đến những
khuyến cáo sau:
• Loại input nào được cho phép bởi ứng dụng
• Đảm bảo rằng tất cả các input được kiểm tra trước khi thực hiện các tiến trình
• Sử dụng phương pháp “white list” hiệu quả hơn là “black list” trong kiểm tra. “white
list” bao gồm việc đồng ý cho các dữ liệu đã biết là tốt trong khi “black list” sử dụng
một danh sách dữ liệu không đươc phép.
• Bổ sung giao thức SSL cho ứng dụng Web
• Nếu là ứng dụng AJAX, giảm thiểu các chương trình logic bị phơi bày
Kết luận
Ứng dụng Web ngày nay chiếm một phần rất quan trọng trong việc trao đổi thông tin trên
mạng. Việc cải tiến các ứng dụng web truyền thống sang các ứng dụng AJAX làm cho nó
nhanh hơn, tiện dụng hơn, dễ dàng tương tác hơn cũng kéo theo hệ quả là tăng nguy cơ mất
an ninh của ứng dụng. Quá trình thực thi Script và thông tin trao đổi trên yêu cầu server/client
tăng đem lại cơ hội lớn hơn cho kẻ tấn công phá hoại hoặc ăn cắp dữ liệu. Một giải pháp tốt
cho vấn đề này là sử dụng các công cụ dò quét, rà soát lỗ hổng của ứng dụng web. Từ đó,
khắc phục các điểm yếu an ninh tồn tại trên ứng dụng.
Nguyễn Anh Đức
10 điều các chuyên gia CNTT cần biết về Ajax
Bất kỳ một công nghệ Web mới nào cũng sẽ đều ảnh hưởng tới một cơ sở hạ t ầng c ủa mạng theo nhi ều
góc độ khác nhau từ những việc không quan trọng đ ến làm choáng váng c ả th ế gi ới. Ajax là m ột trong
các công nghệ mới đang được sử dụng nhiều trên các mạng ngày nay. Để giúp các b ạn có th ể t ối thi ểu
hóa những ngạc nhiên về mạng của mình, chúng tôi phác thảo ra 10 vấn đ ề c ần bi ết v ề Ajax.
1) Ajax là một ý tưởng, không phải là cụm từ
Ajax tuy đã được giải thích rõ ràng là vi ết t ắt c ủa c ụm t ừ Asynchronous JavaScript and XML nh ưng tên
đầy đủ này vẫn không hoàn toàn thích hợp vì nó đơn gi ản hóa quá mức l ịch s ử c ủa công ngh ệ cũng nh ư
những tùy chọn bổ sung nằm trong chính bản thân nó. Chính xác h ơn, Ajax bao g ồm ý t ưởng trong đó
các ứng dụng web có thể được xây dựng để chọn trong số vòng l ặp “post-wait-repeat” đ ược s ử d ụng
trong các ứng dụng Web trình chủ. Ajax cho phép các ứng d ụng web chuy ển m ột cách liên t ục và m ềm
dẻo hơn, nhưng việc update lại tăng lên. Nó cung cấp cho ng ười dùng m ột ph ương pháp phong phú và
khả năng tương tác tốt hơn với những gì nằm bên dưới ứng d ụng Web. Để đ ược thành ph ần này thì các
chuyên gia về mạng càng phải thực hiện nhiều công việc trong kiểm tra và giám sát b ảo m ật c ần thi ết
cũng như khả năng tiềm ẩn sự biến đổi của mạng và máy chủ.
2) Thực sự tất cả theo JavaScript
Các ứng dụng Ajax được viết theo ngôn ng ữ JavaScript và th ường d ựa vào đ ối t ượng XMLHttpRequest
để thực hiện việc truyền thông, cách làm này sẽ tạo ra đường đi của nó thông qua vi ệc x ử lý World Wide
Web. Cũng giống như các công nghệ Web khác, công ngh ệ Ajax lúc này cũng ch ỉ là m ột chu ẩn công
nghệ đặc biệt, những điểm khác nhau nổi bật có thể phát hiện th ấy trong các b ổ sung vào các trình
duyệt khác nhau của nó. Ajax có thể sử dụng các cơ chế truyền t ải d ữ li ệu khác – có ho ặc không có s ự
hỗ trợ rộng rãi trong CNTT – với các ứng dụng Ajax, như frame truyền thống và các ph ương pháp image-
cookie cũng như sử dụng các cầu binary để liên kết với Flash hoặc Java.
Không quan tâm đến phương pháp truyền tải được sử dụng bởi các chuyên gia phát tri ển, Ajax đã làm
cho JavaScript trở nên quan trọng hơn bên trong một ứng d ụng web so v ới nh ững gì nó làm đ ược tr ước
đây. JavaScript lúc này hiện nắm giữ vai trò s ưu t ập các d ữ li ệu quan trọng, truy ền thông và ho ạt đ ộng,
chính vì vậy nó có thể được coi như một công nghệ web lớp th ứ hai không có các tác đ ộng nghiêm
trọng.
Các chuyên gia phát triển phần mềm cho rằng công nghệ JavaScript mang tính đ ộc và mu ốn né tránh
ngôn ngữ này bằng một công cụ hoặc framework tạo nó từ một ngôn ng ữ khác nh ư Java (Google Web
Toolkit là một ví dụ), hoặc dấu các thành phần code ẩn hoặc các tag (nh ư v ới .Net ho ặc Ruby). M ặc dù
vậy JavaScript vẫn là một ứng dụng. Việc tìm hi ểu ứng ngôn ng ữ này và nắm đ ược nó m ột cách tr ực
tiếp sẽ giúp bạn rất nhiều vì nếu muốn sử dụng Ajax thì bạn sẽ s ử dụng đ ến rất nhi ều JavaScript.
3) Không cần đến XML
Mặc dù có chữ “X” trong nhóm từ của Ajax nhưng th ực sự nó không c ần đ ến XML. Đ ối t ượng
XMLHttpRequest có thể truyền tải bất kỳ một định dạng văn b ản nào. V ới nhi ều chuyên gia phát tri ển
phần mềm Ajax, ký hiệu đối tượng JavaScript (JavaScript Object Notation) ho ặc th ậm chí các đo ạn mã
JavaScript thô cũng tạo ra nhiều ý nghĩa như m ột định d ạng d ữ li ệu, cho r ằng JavaScript là môi tr ường
chi phối. Với đầu vào trực tiếp trong các tài liệu, các chuyên gia phát tri ển ph ần m ềm khác có th ể s ử
dụng văn bản thô hoặc các đoạn HTML. Vẫn còn m ột số thành ph ần khác s ử d ụng các đ ịnh d ạng d ữ
liệu như vậy như ngôn ngữ markup YAML ít được biết đến.
Rõ ràng hoàn toàn có thể và hợp lý để s ử dụng XML, nh ưng Ajax v ẫn không yêu c ầu b ắt bu ộc. S ử d ụng
các định dạng nhị phân cho việc upload các file vẫn không đ ược hỗ trợ b ởi đ ối t ượng XMLHttpRequest,
nhưng nên cần biết rằng Flash sử dụng một định dạng nhị phân đ ược g ọi là Action Message Format,
chính vì vậy các tính năng tương t ự như vậy sẽ một s ớm một chi ều có trong các ứng d ụng c ủa Ajax.
Bạn nên biết định dạng nào đang được sử dụng trên mạng vì nó không ph ải lúc nào cũng là XML, và
cũng bảo đảm bạn có thể phân tích định dạng cho vấn đề hiệu suất và b ảo m ật.
4) Kế hoạch cho việc tăng các request HTTP
Vấn đề nổi cộm nhất đối với các quản trị mạng trong việc hỗ trợ các ứng d ụng Ajax là mẫu l ập trình ki ến
trúc đã thay đổi vấn đề sử dụng mạng của các ứng dụng web t ừ việc nh ư x ử lý kh ối, s ự ph ản ứng
không liên tục với hàng trăm KB đến sự thay đổi mang tính liên t ục trong các đáp tr ả HTTP nh ỏ h ơn.
Điều này có nghĩa rằng Web và các máy chủ ứng dụng có thể b ận rộn h ơn tr ước r ất nhi ều. Nh ững gì
Ajax sẽ thực hiện với mạng và máy chủ của bạn ph ụ thuộc vào cách ứng d ụng đ ược thi ết k ế nh ư th ế
nào, hãy bảo đảm cho các chuyên gia phát triển ứng d ụng hi ểu đ ược s ự ảnh h ưởng c ủa các ứng d ụng
của họ với mạng như thế nào.
5) Tối ưu hóa các yêu cầu Ajax một cách thận trọng
Các ứng dụng web nên gắn với trong việc phân phối mạng đó là g ửi ít d ữ li ệu. Tuy v ậy đi ều này không
có nghĩa rằng nguyên lý này cần phải tuân theo m ột cách r ộng rãi b ởi các chuyên gia phát tri ển ph ần
mềm. Một ưu điểm cho mạng, việc nén HTTP cho các đáp trả của Ajax có th ể gi ảm đ ược kích th ước và
được hỗ trợ trong nhiều trình duyệt hiện đại. Tuy vậy vì overhead c ủa file nén mang tính đ ộng nên t ốc
độ có thể không được cải thiện nhiều nếu các đáp trả t ương đ ối nh ỏ. Đi ều này có nghĩa r ằng các qu ản
trị viên mạng nên cho phép nén trên máy chủ Web, nhưng họ cần ph ải hi ểu đ ược rằng v ới các ứng d ụng
Ajax thì hiệu suất của việc này không lớn bằng các ứng dụng web trước kia.
Để gửi dữ liệu ít đi, chúng ta thường sẽ sử dụng đến vấn đề caching. Tuy v ậy h ầu h ết các b ổ sung c ủa
Ajax đều có thể là thù địch của caching với m ột giả đ ịnh là các trình duy ệt mà không liên quan đ ến các
re-fetching URL trong cùng một session. Thay cho làm vi ệc v ới caching thì nhi ều chuyên gia phát tri ển
Ajax lại thủ tiêu caching thông qua thiết lập header hoặc URL đơn nh ất.
Hoàn toàn có thể nhắm đến các vấn đề caching với Ajax cache ở trình khách đ ược vi ết b ằng JavaScript,
nhưng hầu hết các thư viện của Ajax lại không bổ sung tính năng nh ư v ậy. Các chuyên gia v ề m ạng nên
giới thiệu cho các nhà phát triển về lợi ích của caching vì Ajax có th ể s ẽ mang l ại nhi ều l ợi ích t ừ v ấn đ ề
này hơn nén.
6) Thừa nhận về sự hạn chế two-connection
Các ứng dụng Ajax bị hạn chế bởi HTTP đối với hai kết nối đ ồng thời v ới cùng m ột URL. Đây chính là
cách giao thức HTTP được thiết kế, không bị hạn chế. Tuy nhiên có nhi ều chuyên gia phát tri ển ph ần
mềm Ajax vẫn xa lầy vào một máy chủ một cách tình cờ dẫu cho Internet Explorer 8 c ủa Microsoft đ ược
hỗ trợ để thực hiện vượt ra khỏi các hạn chế này. Một s ố ứng d ụng không hay c ủa Ajax có th ể có v ấn
đề và với các trình duyệt đang thay đổi, các quản trị m ạng cần ph ải nắm b ắt đ ược s ố l ượng các yêu c ầu
tạo ra và làm việc với các chuyên gia phát triển ứng d ụng đ ể tránh s ử d ụng các m ẫu thi ết k ế nh ư poll
hoặc các kết nối trợ giúp dài.
7) Xem xét đến thứ tự xử lý
Với các ứng dụng web truyền thống, sự ảnh hưởng truyền thông TCP/IP (nh ư việc thi ếu th ứ t ự đáp tr ả
HTTP nào sẽ được nhận) nhìn chung không được chú ý. Tài li ệu HTML đ ược nh ận tr ước các đ ối t ượng
khác và sau đó nó sẽ kích hoạt yêu cầu. Bất kỳ một yêu c ầu x ảy ra sau đ ều kích ho ạt m ột tài li ệu m ới
hoàn toàn, do đó vẫn bảo đảm được thứ tự. Tuy nhiên Ajax lại không hề s ử d ụng đ ến vi ệc phân đ ịnh th ứ
tự như vậy chính vì vậy sự phụ thuộc của một ứng dụng theo đúng th ứ t ự c ần đ ến m ột hàng đ ợi x ử lý.
Ajax framework cũng không nhất quán thừa nhận mối quan tâm này. Chính vì v ậy c ần ph ải b ảo đ ảm cho
các chuyên gia phát triển ứng dụng Ajax hiểu được vấn đề này.
8) Thừa nhận sự ảnh hưởng của việc loại trừ sửa lỗi "Layer 8"
Một vài năm trở lại đây, người dùng đã khắc phục chất lượng trong vi ệc phân ph ối Web b ằng cách
reloading các trang hoặc nhất nút Back. Đơn gi ản, ng ười dùng thực hi ện nh ư v ậy đ ể giúp gi ảm các v ấn
đề về mạng vì lỗi thường xuất hiện tại các thời đi ểm gi ữa các page paint. Tuy v ậy v ới Ajax, l ỗi ứng d ụng
lại không hiển nhiên như vậy. Người dùng thường bị báo sai về các l ỗi vì vòng quay GIF đ ộng cung c ấp
quá ít thông tin về trạng thái đúng của yêu cầu.
Các chuyên gia phát triển phần mềm là những người thiệt nhi ều nh ất vì nhi ều th ư vi ện không có hi ệu
quả trong việc thừa nhận các timeouts đó xảy ra, nh ững lần retry ph ải xuất hi ện, máy ch ủ và các l ỗi d ữ
liệu ngày càng nhiều. Các chuẩn đoán JavaScript hi ển thị việc truyền thông và các l ỗi mã ít khi đúng
trên phía trình khách, chính vì vậy mà người dùng th ường không hay bi ết. Do đó c ần ph ải có nhi ều ki ểm
tra mức ứng dụng được yêu cầu cho các quản trị viên để hỗ trợ Ajax m ột cách h ợp lý.
9) Những mối đe dọa về bảo mật cũ lại xuất hiện lần thứ hai
Nếu bạn lắng nghe các chuyên gia, thì Ajax có thể gây tăng thêm b ề m ặt t ấn công nh ưng qu ả th ực nó
không kém an toàn hơn các môi trường phát tri ển ứng d ụng web truyền th ống nào vì các đ ầu vào HTTP
đến trình chủ tin cậy đều có cùng các header, chuỗi truy v ấn và body văn b ản. Tuy nhiên n ếu mã trình
khách được tin tưởng hoàn toàn và nhập vào dữ li ệu không đ ược ngăn ch ặn trong nhóm phát tri ển web
thì Ajax có thể gây ra những vấn đề về bảo mật tương t ự như các ứng dụng web truyền thống.
Cross-site scripting (XSS) không phải là lỗ hổng mới trong Ajax; nó là m ột l ỗi chung, đ ặc bi ệt n ếu m ột
ứng dụng nào đó cho phép dữ liệu trạng thái được đi ều ch ỉnh v ới JavaScript. Đ ầu vào HTML c ần đ ược
không cho phép trong hầu hết các trường hợp và HTTP Only Cookies nên đ ược áp d ụng ngay l ập t ức đ ể
giảm việc tấn công cookie và các tấn công khác thông qua XSS.
Cũng vậy Cross Site Request Forgery cũng không ph ải là m ột l ỗi m ới c ủa Ajax, nh ưng n ếu các chuyên
gia phát triển ứng dụng của bạn không kiểm tra HTTP Referer (sic) header và quản lý session đúng cách
bên trong các ứng dụng Ajax thì có thể để hổng vấn đề này.
Các Hacker, cũng giống như các chuyên gia phát tri ển ph ần mềm hi ện đang r ất quan tâm đ ến vi ệc s ử
dụng và lạm dụng JavaScript, điều đó càng làm tăng thêm các l ỗ hổng ti ềm tàng. Các chuyên gia v ề
mạng nên bảo đảm cho chuyên gia phần mềm bi ết được rằng mã trình khách có th ể b ị thay đ ổi, vì v ậy
các dữ liệu đầu vào luôn cần được lọc và xem xét.
10) Vấn đề về chính sách cùng gốc
Một mặt “positive” (mang tính ưu điểm) về bảo mật, các chính sách cùng g ốc c ủa JavaScript s ẽ v ẫn có
hiệu lực trong ứng dụng Ajax sử dụng XMLHttpRequest. Chính sách này b ảo đ ảm cho các k ịch b ản đó
không liên kết với các miền bên ngoài. Từ quan điểm của các chuyên gia phát tri ển ph ần m ềm, đi ều này
có thể khá bực mình vì nó có nghĩa rằng các trang đó đ ược đáp ứng, ví d ụ là t ừ ajaxref.com l ại không
thể liên kết với URL được host trên www.ajaxref.com; th ậm chí nếu nó n ằm trên cùng m ột máy ch ủ thì
cũng không cùng chính xác miền. DNS tương đương không có vấn đề ở đây; nó là m ột string-check
được sử dụng bởi SOP.
SOP sẽ làm vướng khả năng của các chuyên gia phát tri ển trong vi ệc th ực hi ện m ột s ố c ố g ắng cho
dịch vụ Web trên phía trình khách. Rõ ràng phương pháp t ốt nh ất là s ử d ụng proxy trên máy ch ủ đ ể đ ưa
ra các yêu cầu đến máy chủ khác và kết hợp các kết quả. Tuy v ậy, nhi ều chuyên gia phát tri ển ph ần
mềm Ajax lại cố gắng ngắt các hạn chế cùng gốc.
Theo: quantrimang.com
