11. Khía cạnh bảo mật
Là một khuôn khổ linh hoạt và có thể mở rộng, các cân nhắc về bảo mật của OAuth phụ thuộc vào nhiều yếu tố. Các phần sau cung cấp cho người triển khai các nguyên tắc bảo mật tập trung vào ba cấu hình ứng dụng được mô tả theo kiểu ứng dụng: ứng dụng web, ứng dụng dựa trên tác nhân người dùng và ứng dụng được phát triển riêng.
[OAuth-THREATMODEL] cung cấp mô hình và phân tích bảo mật OAuth toàn diện cũng như nền tảng cho thiết kế giao thức.
Dưới đây là cách khía cạnh bảo mật mà đã từng bị tấn công hoặc là phần yếu của khung kết nối ủy quyền này.
a) Xác thực bảo mật
Máy chủ ủy quyền thiết lập thông tin xác thực ứng dụng với các ứng dụng ứng dụng web nhằm mục đích xác thực ứng dụng. Máy chủ ủy quyền được khuyến khích coi phương tiện xác thực ứng dụng mạnh hơn là mật khẩu ứng dụng. Ứng dụng web PHẢI đảm bảo tính bảo mật của mật khẩu ứng dụng và các "thông tin đăng nhập ứng dụng" khác.
Máy chủ ủy quyền KHÔNG PHẢI cấp mật khẩu ứng dụng hoặc thông tin đăng nhập ứng dụng khác cho ứng dụng gốc hoặc ứng dụng dựa trên tác nhân người dùng nhằm mục đích xác thực ứng dụng. Máy chủ ủy quyền CÓ THỂ cấp mật khẩu ứng dụng hoặc thông tin đăng nhập khác để cài đặt cụ thể một ứng dụng khách gốc trên một thiết bị cụ thể.
Khi không thể xác thực ứng dụng, máy chủ ủy quyền NÊN sử dụng các phương tiện khác để xác thực danh tính của ứng dụng - ví dụ: bằng cách yêu cầu đăng ký URI chuyển hướng ứng dụng hoặc nhờ chủ sở hữu tài nguyên xác nhận danh tính. URI chuyển hướng hợp lệ không đủ để xác minh danh tính của khách hàng khi yêu cầu ủy quyền của chủ sở hữu tài nguyên nhưng có thể được sử dụng để ngăn việc cung cấp thông tin xác thực cho khách hàng giả mạo sau khi có được ủy quyền của chủ sở hữu tài nguyên.
b) Mạo danh ứng dụng
Một ứng dụng độc hại có thể mạo danh một ứng dụng khác và có quyền truy cập vào các tài nguyên được bảo vệ nếu ứng dụng bị mạo danh kém hoặc không thể giữ bí mật thông tin đăng nhập của ứng dụng khách của mình.
Máy chủ ủy quyền PHẢI xác thực ứng dụng bất cứ khi nào có thể. Nếu máy chủ ủy quyền không thể xác thực ứng dụng do bản chất của ứng dụng khách, máy chủ ủy quyền PHẢI yêu cầu đăng ký bất kỳ URI chuyển hướng nào được sử dụng để nhận phản hồi ủy quyền và NÊN sử dụng các phương tiện khác để bảo vệ chủ sở hữu tài nguyên khỏi các ứng dụng độc hại tiềm ẩn như vậy. Ví dụ: máy chủ ủy quyền có thể thu hút chủ sở hữu tài nguyên để hỗ trợ xác định ứng dụng và nguồn gốc của nó.
Máy chủ ủy quyền NÊN thực thi xác thực chủ sở hữu tài nguyên rõ ràng và cung cấp cho chủ sở hữu tài nguyên thông tin về ứng dụng cũng như phạm vi ủy quyền được yêu cầu và thời gian tồn tại. Chủ sở hữu tài nguyên có quyền xem xét thông tin trong ngữ cảnh của ứng dụng hiện tại và cho phép hay từ chối yêu cầu.
Máy chủ ủy quyền KHÔNG NÊN xử lý các yêu cầu ủy quyền lặp lại một cách tự động (không có sự tương tác của chủ sở hữu tài nguyên đang hoạt động) mà không xác thực ứng dụng hoặc dựa vào các biện pháp khác để đảm bảo rằng yêu cầu lặp lại đến từ ứng dụng gốc chứ không phải người mạo danh.
c) Mã thông báo truy cập
Thông tin đăng nhập mã thông báo truy cập (cũng như bất kỳ thuộc tính mã thông báo truy cập bí mật nào) PHẢI được giữ bí mật trong quá trình vận chuyển và lưu trữ và chỉ được chia sẻ giữa máy chủ ủy quyền, máy chủ tài nguyên mà mã thông báo truy cập hợp lệ và khách hàng được cấp mã thông báo truy cập. Thông tin đăng nhập mã thông báo truy cập PHẢI chỉ được truyền bằng TLS như được mô tả ở phần 1 và có sự xác thực máy chủ như được xác định bởi [RFC2818].
Khi sử dụng kiểu cấp ngầm, mã thông báo truy cập được truyền trong phân đoạn URI, có thể để lộ nó cho các bên không được phép.
Máy chủ ủy quyền PHẢI đảm bảo rằng các mã thông báo truy cập không thể được tạo, sửa đổi hoặc đoán để tạo ra mã thông báo truy cập hợp lệ bởi các bên không được ủy quyền.
Các ứng dụng NÊN yêu cầu mã thông báo truy cập với phạm vi tối thiểu cần thiết. Máy chủ ủy quyền NÊN tính đến danh tính khách hàng khi chọn cách đáp ứng phạm vi được yêu cầu và CÓ THỂ phát hành mã thông báo truy cập với ít quyền hơn yêu cầu.
Thông số kỹ thuật này không cung cấp bất kỳ phương pháp nào cho máy chủ tài nguyên để đảm bảo rằng mã thông báo truy cập được cung cấp bởi một ứng dụng nhất định đã được máy chủ ủy quyền cấp cho ứng dụng đó.
d) Mã ủy quyền
Việc truyền mã ủy quyền NÊN được thực hiện qua một kênh an toàn và ứng dụng NÊN yêu cầu sử dụng TLS với URI chuyển hướng của nó nếu URI xác định tài nguyên mạng. Vì mã ủy quyền được truyền qua chuyển hướng tác nhân người dùng, chúng có thể bị tiết lộ thông qua lịch sử tác nhân người dùng và tiêu đề liên kết giới thiệu HTTP.
Mã ủy quyền hoạt động như thông tin xác thực, được sử dụng để xác minh rằng chủ sở hữu tài nguyên đã cấp phép tại máy chủ ủy quyền là chủ sở hữu tài nguyên tương tự quay lại máy khách để hoàn tất quy trình. Do đó, nếu máy khách dựa vào mã ủy quyền để xác thực chủ sở hữu tài nguyên của chính nó, thì điểm cuối chuyển hướng máy khách PHẢI yêu cầu sử dụng TLS.
Mã ủy quyền PHẢI tồn tại trong thời gian ngắn và sử dụng một lần. Nếu máy chủ ủy quyền quan sát thấy nhiều lần cố gắng trao đổi mã ủy quyền lấy mã thông báo truy cập, máy chủ ủy quyền NÊN cố gắng thu hồi tất cả các mã thông báo truy cập đã được cấp dựa trên mã ủy quyền bị xâm phạm.
Nếu ứng dụng có thể được xác thực, máy chủ ủy quyền PHẢI xác thực ứng dụng và đảm bảo rằng mã ủy quyền được cấp cho cùng một ứng dụng.
e) Thao tác URI chuyển hướng mã ủy quyền
Khi yêu cầu ủy quyền bằng kiểu cấp mã ủy quyền, ứng dụng có thể chỉ định URI chuyển hướng thông qua tham số "redirect_uri". Nếu kẻ tấn công có thể thao túng giá trị của URI chuyển hướng, nó có thể khiến máy chủ ủy quyền chuyển hướng tác nhân người dùng của chủ sở hữu tài nguyên đến một URI dưới sự kiểm soát của kẻ tấn công bằng mã ủy quyền.
Kẻ tấn công có thể tạo một tài khoản tại một ứng dụng hợp pháp và bắt đầu quy trình ủy quyền. Khi tác nhân người dùng của kẻ tấn công được gửi đến máy chủ ủy quyền để cấp quyền truy cập, kẻ tấn công lấy URI ủy quyền do máy khách hợp pháp cung cấp và thay thế URI chuyển hướng của ứng dụng bằng một URI dưới sự kiểm soát của kẻ tấn công. Sau đó, kẻ tấn công lừa nạn nhân đi theo liên kết bị thao túng để cho phép truy cập vào ứng dụng hợp pháp.
Sau khi ở máy chủ ủy quyền, nạn nhân được nhắc với một yêu cầu bình thường, hợp lệ thay mặt cho một ứng dụng hợp pháp và đáng tin cậy, đồng thời ủy quyền yêu cầu. Sau đó, nạn nhân được chuyển hướng đến một điểm cuối dưới sự kiểm soát của kẻ tấn công bằng mã ủy quyền. Kẻ tấn công hoàn thành luồng ủy quyền bằng cách gửi mã ủy quyền đến ứng dụng bằng URI chuyển hướng ban đầu do máy khách cung cấp. Ứng dụng trao đổi mã ủy quyền với một mã thông báo truy cập và liên kết nó với tài khoản khách hàng của kẻ tấn công, tài khoản này hiện có thể có quyền truy cập vào các tài nguyên được bảo vệ do nạn nhân ủy quyền (thông qua ứng dụng).
Để ngăn chặn một cuộc tấn công như vậy, máy chủ ủy quyền PHẢI đảm bảo rằng URI chuyển hướng được sử dụng để lấy mã ủy quyền giống hệt với URI chuyển hướng được cung cấp khi trao đổi mã ủy quyền lấy mã thông báo truy cập. Máy chủ ủy quyền PHẢI yêu cầu ứng dụng công khai và NÊN yêu cầu máy khách bí mật đăng ký URI chuyển hướng của họ. Nếu URI chuyển hướng được cung cấp trong yêu cầu, máy chủ ủy quyền PHẢI xác thực nó so với giá trị đã đăng ký.
f) Kiểu cấp phép “thông tin đăng nhập mật khẩu của chủ sở hữu tài nguyên”
Loại cấp thông tin xác thực mật khẩu của chủ sở hữu tài nguyên thường được sử dụng cho các lý do kế thừa hoặc di chuyển. Nó làm giảm nguy cơ tổng thể của việc lưu trữ tên người dùng và mật khẩu của ứng dụng nhưng không loại bỏ khả năng để lộ thông tin xác thực có đặc quyền cao cho ứng dụng.
Loại cấp phép này có rủi ro cao hơn các loại cấp phép khác vì nó duy trì kiểu chống mật khẩu mà giao thức này tìm cách tránh. Ứng dụng có thể lạm dụng mật khẩu hoặc mật khẩu có thể vô tình bị tiết lộ cho kẻ tấn công (ví dụ: thông qua tệp nhật ký hoặc các bản ghi khác được ứng dụng lưu giữ).
Ngoài ra, vì chủ sở hữu tài nguyên không có quyền kiểm soát quá trình ủy quyền (sự tham gia của chủ sở hữu tài nguyên kết thúc khi họ chuyển giao thông tin đăng nhập của mình cho ứng dụng), ứng dụng có thể nhận được mã thông báo truy cập với phạm vi rộng hơn mong muốn của chủ sở hữu tài nguyên. Máy chủ ủy quyền nên xem xét phạm vi và thời gian tồn tại của các mã thông báo truy cập được cấp thông qua loại tài trợ này.
Máy chủ ủy quyền và ứng dụng NÊN giảm thiểu việc sử dụng loại cấp phép này và sử dụng các loại cấp phép khác bất cứ khi nào có thể.
- Đảm bảo tính xác thực của điểm cuối:
Để ngăn chặn các cuộc tấn công “man-in-the-middle” hay kiểu tấn công “kẻ đứng giữa”, máy chủ ủy quyền PHẢI yêu cầu sử dụng TLS với xác thực máy chủ như được định nghĩa bởi [RFC2818] đối với bất kỳ yêu cầu nào được gửi đến điểm cuối cấp quyền và mã thông báo. Ứng dụng PHẢI xác thực chứng chỉ TLS của máy chủ ủy quyền như được xác định bởi [RFC6125] và phù hợp với các yêu cầu của nó đối với xác thực danh tính máy chủ.
- Tấn công mật khẩu cơ bản:
Máy chủ ủy quyền PHẢI ngăn những kẻ tấn công đoán mã thông báo truy cập, mã ủy quyền, mã làm mới, mật khẩu chủ sở hữu tài nguyên và thông tin đăng nhập vào ứng dụng.
Xác suất kẻ tấn công đoán được các mã thông báo được tạo (và các thông tin xác thực khác không dành cho người dùng cuối xử lý) PHẢI nhỏ hơn hoặc bằng 2 ^ (- 128) và NÊN nhỏ hơn hoặc bằng 2 ^ (- 160).
Máy chủ ủy quyền PHẢI sử dụng các phương tiện khác để bảo vệ thông tin xác thực dành cho người dùng cuối.
g) Tấn công Phishing.
Hình 1: Tấn công thông qua xây dựng ứng dụng
Đây là kiểu tấn công mạng bằng cách xây dựng cả một hệ thống lừa đảo nhằm ăn cắp thông tin truy cập của người dùng. Phishing xuất hiện như một ứng dụng hay một website đáng tin cậy, một trang thông tin điện tử… Phishing thường được thực hiện qua email, lấy tên của các ứng dụng hay website uy tín gửi cảnh báo hoặc một link thưởng hoặc quà để lừa người sử dụng. Sau khi ấn vào link thì người dùng sẽ bị dẫn đến website lừa đảo.
Có một điều đáng chú ý là người dùng thường không để ý kĩ vào tên của link. Điều này tạo ra một kiểu tấn công là giả mạo đường dẫn. Ví dụ thay vì bạn nhận được mail của www.facebook.com thì lại nhận được mail của www.faceboook.com và do không để í việc là cái tên giả có thừa một chữ “o” mà người sử dụng dễ dàng bị kẻ tấn công lừa.
Để tránh bị tấn công Phishing thì người dùng cần chú ý vào các mail thông báo lạ, nên đọc kĩ thông tin của mail hay tin trước khi ấn chọn link. Sử dụng bảo mật 2 lớp trở lên.
h) Tấn công CSRF
CSRF hay 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 dùng đối với một webiste.
Giả mạo yêu cầu trên nhiều trang web (CSRF) là cách khai thác trong đó kẻ tấn công khiến tác nhân người dùng của người dùng cuối nạn nhân theo một URI độc hại (ví dụ: được cung cấp cho tác nhân người dùng dưới dạng liên kết, hình ảnh hoặc chuyển hướng gây hiểu lầm) đến một máy chủ tin cậy (thường được thiết lập thông qua sự hiện diện của cookie phiên hợp lệ).
Một cuộc tấn công CSRF chống lại URI chuyển hướng của ứng dụng cho phép kẻ tấn công đưa mã ủy quyền hoặc mã truy cập của chính nó, mã này có thể dẫn đến khách hàng bằng cách sử dụng mã truy cập được liên kết với các tài nguyên được bảo vệ của kẻ tấn công chứ không phải của nạn nhân (ví dụ: lưu thông tin tài khoản ngân hàng của nạn nhân để một tài nguyên được bảo vệ do kẻ tấn công kiểm soát).
Ứng dụng PHẢI triển khai bảo vệ CSRF cho URI chuyển hướng của nó. Điều này thường được thực hiện bằng cách yêu cầu bất kỳ yêu cầu nào được gửi đến điểm cuối URI chuyển hướng phải bao gồm một giá trị liên kết yêu cầu với trạng thái được xác thực của tác nhân người dùng (ví dụ: hàm băm của cookie phiên được sử dụng để xác thực tác nhân người dùng). Máy khách NÊN sử dụng tham số yêu cầu "trạng thái" để phân phối giá trị này đến máy chủ ủy quyền khi thực hiện yêu cầu ủy quyền.
Khi đã nhận được ủy quyền từ người dùng cuối, máy chủ ủy quyền sẽ chuyển hướng tác nhân người dùng của người dùng cuối trở lại máy khách với giá trị ràng buộc bắt buộc có trong tham số "trạng thái". Giá trị ràng buộc cho phép khách hàng xác minh tính hợp lệ của yêu cầu bằng cách khớp giá trị ràng buộc với trạng thái được xác thực của tác nhân người dùng. Giá trị liên kết được sử dụng để bảo vệ CSRF PHẢI chứa một giá trị không thể đoán được và trạng thái được xác thực của tác nhân người dùng (ví dụ: cookie phiên, bộ nhớ cục bộ HTML5) PHẢI được giữ ở một vị trí mà chỉ ứng dụng khách và tác nhân người dùng mới có thể truy cập được (tức là, được bảo vệ bởi chính sách cùng nguồn gốc).
i) Tấn công Clickjacking
Hình 2: Tấn công Clickjacking
Trong một cuộc tấn công clickjacking, kẻ tấn công đăng ký một ứng dụng hợp pháp và sau đó tạo một trang web độc hại, trong đó nó tải trang web điểm cuối ủy quyền của máy chủ ủy quyền trong một iframe ẩn được phủ lên trên một tập hợp các nút giả, được xây dựng cẩn thận để được đặt ngay dưới các nút quan trọng trên trang ủy quyền. Khi người dùng cuối nhấp vào nút hiển thị gây hiểu lầm, người dùng cuối thực sự đang nhấp vào nút ẩn trên trang ủy quyền (chẳng hạn như nút "Ủy quyền"). Điều này cho phép kẻ tấn công lừa chủ sở hữu tài nguyên cấp quyền truy cập cho máy khách mà người dùng cuối không biết.
Để ngăn chặn hình thức tấn công này, các ứng dụng gốc NÊN sử dụng các trình duyệt bên ngoài thay vì nhúng các trình duyệt trong ứng dụng khi yêu cầu ủy quyền người dùng cuối. Đối với hầu hết các trình duyệt mới hơn, máy chủ ủy quyền có thể thực thi việc tránh iframe bằng cách sử dụng tiêu đề "x-frame-options" (không chuẩn). Tiêu đề này có thể có hai giá trị, "từ chối" và "sameorigin", sẽ chặn mọi hành vi đóng khung bởi các trang web có nguồn gốc khác, tương ứng. Đối với các trình duyệt cũ hơn, kỹ thuật chặn khung JavaScript có thể được sử dụng nhưng có thể không hiệu quả trong tất cả các trình duyệt.
j) Chèn mã và can thiệt đầu vào
Một cuộc tấn công chèn mã xảy ra khi một đầu vào hoặc biến bên ngoài được sử dụng bởi một ứng dụng không được bảo vệ và gây ra sửa đổi đối với logic ứng dụng. Điều này có thể cho phép kẻ tấn công giành quyền truy cập vào thiết bị ứng dụng hoặc dữ liệu của nó, gây ra từ chối dịch vụ hoặc gây ra một loạt các tác dụng phụ độc hại.
Tùy thuộc vào mức độ tinh vi, tấn công chèn mã cho phép kẻ tấn công vượt qua quá trình xác thực truy cập chủ yếu vào cơ sở dữ liệu và sau đó ảnh hưởng xấu đến dữ liệu người dùng.
Máy chủ và ứng dụng ủy quyền PHẢI dọn dẹp (và xác thực khi có thể) bất kỳ giá trị nào nhận được khả nghi - đặc biệt là giá trị của các tham số "state" và "redirect_uri".
k) Tấn công Open Redirect
Máy chủ ủy quyền, điểm cuối ủy quyền và điểm cuối chuyển hướng ứng dụng có thể được định cấu hình không đúng cách và hoạt động như các bộ chuyển hướng mở. Công cụ chuyển hướng mở là một điểm cuối sử dụng tham số để tự động chuyển hướng tác nhân người dùng đến vị trí được chỉ định bởi giá trị tham số mà không cần bất kỳ xác thực nào.
Các trình chuyển hướng mở có thể được sử dụng trong các cuộc tấn công lừa đảo hoặc bởi kẻ tấn công để khiến người dùng cuối truy cập các trang web độc hại bằng cách sử dụng thành phần quyền URI của một điểm đến quen thuộc và đáng tin cậy. Ngoài ra, nếu máy chủ ủy quyền cho phép ứng dụng chỉ đăng ký một phần của URI chuyển hướng, kẻ tấn công có thể sử dụng trình chuyển hướng mở do ứng dụng vận hành để xây dựng URI chuyển hướng sẽ vượt qua xác thực máy chủ ủy quyền nhưng sẽ gửi mã ủy quyền hoặc quyền truy cập mã thông báo đến một điểm cuối dưới sự kiểm soát của kẻ tấn công
Một số điều hướng dễ nhận biết ví dụ như: redirect_to=, checkout_url=, domain_name=, … đôi khi có thể rút gọn lại như: r=, u= …
l) Sử dụng sai Mã thông báo truy cập để mạo danh chủ sở hữu tài nguyên trong luồng ngầm
Đối với các ứng dụng khách công cộng sử dụng các luồng ngầm định, đặc tả này không cung cấp bất kỳ phương pháp nào để ứng dụng xác định mã thông báo truy cập được cấp cho khách hàng nào.
Chủ sở hữu tài nguyên có thể sẵn sàng ủy quyền quyền truy cập vào tài nguyên bằng cách cấp mã thông báo truy cập cho máy khách độc hại của kẻ tấn công. Điều này có thể là do lừa đảo hoặc một số lý do khác. Kẻ tấn công cũng có thể đánh cắp mã thông báo thông qua một số cơ chế khác. Sau đó, kẻ tấn công có thể cố gắng mạo danh chủ sở hữu tài nguyên bằng cách cung cấp mã thông báo truy cập cho một khách hàng công khai hợp pháp.
Trong quy trình ngầm định (response_type = token), kẻ tấn công có thể dễ dàng chuyển đổi mã thông báo trong phản hồi từ máy chủ ủy quyền, thay thế mã thông báo truy cập thực bằng mã đã cấp trước đó cho kẻ tấn công.
Máy chủ giao tiếp với các ứng dụng gốc dựa vào việc được thông qua mã thông báo truy cập trong kênh phía sau để xác định người dùng của máy khách có thể bị xâm phạm tương tự bởi kẻ tấn công tạo ra một ứng dụng bị xâm nhập có thể đưa mã thông báo truy cập bị đánh cắp tùy ý.
Bất kỳ ứng dụng khách công khai nào giả định rằng chỉ chủ sở hữu tài nguyên mới có thể trình bày nó với mã thông báo truy cập hợp lệ cho tài nguyên đều dễ bị tấn công kiểu này.
Loại tấn công này có thể tiết lộ thông tin về chủ sở hữu tài nguyên tại máy khách hợp pháp cho kẻ tấn công (máy khách độc hại). Điều này cũng sẽ cho phép kẻ tấn công thực hiện các hoạt động tại máy khách hợp pháp với các quyền tương tự như chủ sở hữu tài nguyên ban đầu đã cấp mã thông báo truy cập hoặc mã ủy quyền.
Việc xác thực chủ sở hữu tài nguyên cho khách hàng nằm ngoài phạm vi của đặc điểm kỹ thuật này. Bất kỳ thông số kỹ thuật nào sử dụng quy trình ủy quyền như một hình thức xác thực người dùng cuối được ủy quyền cho máy khách (ví dụ: dịch vụ đăng nhập của bên thứ ba) KHÔNG ĐƯỢC sử dụng quy trình ngầm định mà không có các cơ chế bảo mật bổ sung cho phép ứng dụng xác định xem quyền truy cập mã thông báo đã được phát hành để sử dụng (ví dụ: mã thông báo truy cập hạn chế đối tượng).
12. Kết luận
Tiếp nối phần 1, phần 2 đã đi sâu và đưa ra một cách hoàn thiện khía cạnh bảo mật trong khung kết nối. Mặc dù khung kết nối ủy quyền OAuth2.0 có một lượng lớn các yếu tố thiếu tính bảo mật có thể để tin tặc hay hacker tấn công nhưng việc nắm bắt được nội dung và hiểu được khung kết nối ủy quyền này là hoàn toàn cần thiết. Chính là bởi trải qua chiều dài lịch sử phát triển, đây là khung nền tảng để xây dựng các tiêu chuẩn và nền tảng mới về yếu tố ủy quyền trên các nền tảng mảng.
Thông qua khung ủy quyền này, ta có thêm các khía cạnh về bảo mật để xây dựng các nền tảng mới trong khung chính phủ điện tử hướng tới xây dựng và phát triển chính phủ điện tử 2.0.
Vũ Cao Minh Đức
Tài liệu tham khảo
1. Hardt, D., “The OAuth 2.0 Authorization Framework,” RFC 6749, October 2012 (TXT).
2. Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. và T. Berners-Lee, "Hypertext Transfer Protocol - HTTP / 1.1", RFC 2616, June 1999.
3. D Scott, R Sharp, “Abstracting application-level web security”, the 11th international conference on World Wide Web, 2002.