Chi phí bảo mật. Việc gọi các dịch vụ hoặc chức năng truyền thống phục vụ cho việc ra quyết định, mã hóa và giải mã dừ liệu, kiểm tra sự sẵn sàng và xác nhận tính toàn vẹn tiêu tốn thời gian và tài nguyên của hệ thống. Tuy nhiên những công việc trên là bẳt buộc để giúp hệ thống tránh khỏi những nguy cơ trong tương lai. v ề bản chất, bảo đảm an toàn cho hệ thống là phải tìm ra cách cân bàng giữa các nguy cơ hiện hữu và hiệu năng. Do sự an toàn của hệ thống ảnh hưởng tới hiệu năng, nên nó cũng có thế ảnh hưởng tới trạng thái của dịch vụ. Xuất phát từ khung nhìn của công việc kinh doanh, dường như các dịch vụ là không có trạng thái. Tuy nhiên, khi một dịch vụ yêu cầu thì cần phải xác định xem dịch vụ đó được chấp nhận thực hiện yêu cầu và nhìn thấy kết quả hay không. Để có thể ra quyết định cho việc này, người phát triển cần một sổ dữ liệu mà không thường xuyên được truyền đi khi một dịch vụ tiến hành cuộc gọi yêu cầu. Kết quả là, một ứng dụng backend có thể lấy dừ liệu nhận dạng đầu vào và sứ dụng nó để tải thông tin cá nhân của người dùng và quyền được truy cập cua người dùng với dữ liệu đó. Thực hiện việc này có thể tốn một khoảng thời gian nhất định. Thêm vào đó, nếu dịch vụ được định tuyến đến các hệ thống cung cấp khác nhau, hệ thống sẽ phải tải thông tin cá nhân và quyền của người dùng trên mỗi yêu cầu, hoặc ít nhất với yêu cầu đầu tiên bên trong mỗi hệ thống cung cấp. Thông tin cá nhân và quyền của dịch vụ có thể được lưu trữ để khi có yêu cầu được chuyển đến cùng một hệ thống về mặt vật lý một lần nữa, dữ liệu phải được nạp từ yêu cầu đầu tiên. Trong trường hợp này, hệ thống có thể trả về một mã thông báo (token) được sử dụng với mồi yêu cầu thêm. Tuy nhiên, sau đó việc xác định xem sau bao lâu dừ liệu lưu trừ đó vẫn còn hợp lệ cần được thực hiện, cần chú ý rằng có nhiều cách khác nhau đê giải quyết vấn đề trạng thái và dịch vụ. Ví dụ, ta có thể chỉ giải quyết vấn đề trạng thái
trong các ứng dụng backend và sử dụng một mã phiên làm việc trả về với yêu cầu dịch vụ đầu tiên và gửi nó đi với tất cả các lời gọi dịch vụ thêm vào.
/. 9.4 Bảo mật trong thực tế
Neu người viết có thể miêu tả nội dung của việc bảo mật đã được chứng kiến trong thực tế, thì tất cả những gì có thể nói sẽ là một công việc rất phức tạp: nó có thê liên quan đến việc quản lý tập trung người sử dụng, một số người sử dụng có kỳ thuật, sự mã hóa trên các tầng ứng dụng khác nhau,... Một sự kết hợp hỗn độn cua những nội dung về bảo mật, nhận dạng nhà cung cấp và những giải pháp bảo mật khác được su dựng ngày nay. Ngoài ra, thường có ít nhất một phần nào đó không liên quan đến bao mật. về mặt lý thuyết, điều này hoàn toàn có thể xảy ra và đôi khi thực sự gây lo lắng. Ví dụ một khu vực phi quân sự (DMZ) là vùng mà mỗi hệ thống tin tưởng các hệ thống khác và sự bảo mật chỉ đóng vai trò khi có dữ liệu được gửi ra khỏi vùng đó. Điều này có nghĩa rằng tất cả các ứng dụng backend bên trong vùng đó tin tưởng tất ca các ứng dụng ở vùng biên, được coi như một bức tường lửa cho công ty ( ví dụ như máy chủ cổng thông tin, các ứng dụng yêu cầu,...). Rõ ràng là những ứng dụng biên phai chia sẻ chung chính sách an toàn và triển khai các chính sách này một cách chính xác. Ví dụ, thay vì chú trọng khả năng xử lý nhiều cuộc gọi từ các client trên mỗi ứng dụng backend, bây giờ tất cả người sử dụng bên trong vùng an toàn (DMZ) có thê được chấp nhận lấy dừ liệu. Sau đó điều cần thực hiện là bảo đảm ràng tất cá ứng dụng cũng như người sử dụng bên ngoài vùng an toàn sẽ chỉ nhìn thấy dừ liệu tương ứng với công ty hay phạm vi miền của họ. Thật không may, nhà cung cấp dịch vụ (cũng là người sở hữu dữ liệu) không thể hoàn toàn bảo đảm rằng vai trò công việc sẽ liên quan tương ứng đến quyền truy cập dữ liệu, vì việc triển khai các điều luật đó yêu cầu sự hợp tác của nhiều nhà sử dụng dịch vụ. Điều này có thể làm cho công việc kiểm soát rất phức tạp, nếu không muốn nói là không thể.
Phương pháp tiếp cận DMZ đã từng được sử dụng cho những dữ liệu nhạy cảm. Ví dụ, khi gọi một dịch vụ trả lại dữ liệu cho từng người sử dụng. Do dữ liệu của những nhà quản lý hay những nhân vật quan trọng cần chỉ được truy cập bởi một số ít người đặc biệt, cách tiếp cận này mang lại nhiều rủi ro. Để giảm bớt rủi ro, trong một số trường họp có thể áp dụng chính sách mã hóa dữ liệu bằng cách gán tên giả cho khách hàng và chỉ cung cấp cho một số ít người cần thiết danh sách nối giữa tên giả và tên thật. Có thể thấy đây là một ví dụ rất thú vị trong việc xử lý vấn đề an toàn trong tầng nghiệp vụ doanh nghiệp.
Việc kiểm toán (auditing) cũng đóng vai trò quan trọng trong việc bảo mật cho hệ thống. Khi người quản lý hệ thống có khả năng theo dõi và đối chiếu luồng dừ liệu thì sau này họ sẽ có khả năng tìm hiểu xem người nào hoặc điều gì là nguyên nhân gây ra mất an ninh cho hệ thống cũng như những mối đe dọa tới hệ thống. Hiêu theo một cách khác, bằng cách quản lý truy nhập, theo dõi và kiếm soát dòng thông tin, người quản trị có thể khuyến khích những lập trình viên chịu trách nhiệm nhiều hơn hoặc
36
thận trọng hơn với những vấn đề liên quan đến bảo mật, và ngăn chặn việc vi phạm an ninh cua hệ thống. Neu người quản trị không thể ngăn chặn việc vi phạm bao mật cho hệ thống thì ít nhất anh ta cũng có thể tìm hiểu được việc gì đà xáy ra và người gây ra. Việc tồn tại nguy cơ xảy ra với hệ thống ờ mức cao hay không hoàn toàn phụ thuộc vào phương pháp tiếp cận và quản lý an toàn cho hệ thống của người quản trị.
1.9.5 Bảo măt với XML và Web Service•
Trong phần này, một số gợi ý liên quan đến vấn đề bảo mật với XML và các web service sẽ được trình bày. v ề nguyên tắc, người quản trị có thể sử dụng những chuấn khac nhau, bao gồm những chuẩn sau:
- Chuẩn bảo mật thông thường. - Chuẩn bảo mật dành cho XML.
- Chuân bảo mật giành cho các web service.
Web Services Security S tan d a rd s '.V S-S ecLriry. '.v s -P o lic y . VVS-_r L s : . ... General XML-based Security S tan d ard s
SAMLXACML...
XML Security S tandard s
XML En cry p tio n ,X M L S ig nature ....
General Security S tan d ard s
K erberos. PKI. X .S 09, SSI__
Security A lg o rith m s A E S . D E S .R S A ....
4Hình 1.10: Các tầng bảo mật cho XML và các web service
Cá; chuẩn bảo mật thông thường bao gồm những thuật toán nổi tiếng như RSA, AES, DES và các chuẩn an toàn cơ bản cho cho việc mã hóa và bảo đảm an toàn cho việc tĩra) đồi thông tin như SSL, Kerberos,... Ngoài ra, có một số chuẩn đặc biệt dành cho tái liệu XML. Điểm thuận lợi là các chuẩn này cho phép đọc và ghi lên các file XML, mhor đó việc mã hóa chữ ký có thể được tiến hành bằng cách sử dụng chuồi XML tlhcng thường. Cuối cùng, tại đỉnh của sơ đồ các tầng bảo mật là các chuẩn bảo mật tlhcng thường của XML, ví dụ như SAML và các chuẩn dành cho web service như WS-Security. Phần tiếp theo sẽ trình bày tóm lược về một sổ chuẩn quan trọng,
n Security Assertion Markup Language (SAML)
Một chuẩn chung quan trọng, được duy trì và phát hành bởi OASIS. SAML là một mgìn ngừ dựa trên XML dành cho việc quản lý và trao đổi thông tin bảo mật giữa các h ệ thống khác nhau. Nó cho phép một bên có thể xác nhận thông tin bao mật về một chi đề (ví dụ như một sự nhận dạng thường xuyên cho người sử dụng hoặc có thế là
các nhân viên kỹ thuật, hệ thống hoặc một công ty). Các thuộc tính khác cũng có thê được xác nhận bô sung như địa chi email của khách hàng hoặc vai trò của người dùng. Ví dụ, một sự xác nhận có thể như sau: “Đó là Nicolai Smiths, có địa chỉ email là n.sa)somedomain.de, là người được phép chỉnh sửa nội dung của quyên sách này” Sự xác nhận có thể được quản lý và trao đổi trong môi trường phân tán. Ví dụ, giao thức cho phép nhận dạng người cung cấp để xác định một chủ đề, thông qua sự xác nhận, ánh xạ giữa các sự nhận dạng khác nhau, và thực hiện việc thoát khỏi hệ thống phản tán (single logouts hay SLO). Kết quả là người quản trị có thế quản lý và kết hợp các thông tin cá nhân của nhiều người sử dụng khác nhau bằng cách sử dụng nhận dạng nhà cung cấp trên các tiến trình phân tán. Điều này bao gồm cả việc hồ trợ của đăng nhập một lần (single sign on).
□ XML và các chuẩn an toàn cho các web service
Có một số chuẩn đặc biệt tồn tại đối với XML và các web service. Những chuấn nàv không giới thiệu công nghệ hay thủ tục bảo mật mới, mà tập trung vào việc định nghĩa làm cách nào đe áp dụng các công nghệ và các thù tục đang tồn tại vào việc trao đổi dừ liệu thông qua các file XML hay các web service.
Ví iụ, các chuẩn giành XML như:
- XML Signature (XML DSig): Cho phép các tài liệu XML sẽ được ký để đảm báo trim toàn vẹn và tính xác thực của dữ liệu.
- XML Encryption (XML Enc): Cho phép các tài liệu XML có thế được mã hóa toàn hộ hoặc một phần. Ví dụ, người sử dụng có thể mã hóa toàn bộ tài liệu XML, hoặc chi rmâ hóa một số dữ liệu trong tài liệu đó, như số thẻ tín dụng hoặc mă hóa toàn bộ thông tĩin ngoại trừ tên người dùng.
- XML Key Management: Hỗ trợ chính cho việc quản lý chuẩn XML Signature.
Các chuân quan trọng cho các web service như:
- V^S-Security: Định nghĩa cách áp dụng các kỹ thuật bảo mật khác nhau cho việc xác tỉhực, toàn vẹn, và các quyền riêng tư cho web service (SOAP): Miêu tả theo tiêu
C:hiẩn cách nhúng các thông tin an toàn như thẻ, mã hóa, chữ ký, SAML, Kerberos, ...
tircng một tiêu đề SOAP.
- VS-Security Policy: Cho phép người dùng có thể tìm ra các chuấn báo mật mà một mhi cung cấp dịch vụ hỗ trợ. Như là một phần của việc định nghĩa các web service tiroig WSDL hay ƯDDI, một nhà cung cấp có thể định nghĩa đó, như là chấp nhận X.509 và Kerberos, và yêu cầu một số chừ ký xác định.
- VS-Trust: Cho phép thay đổi, làm mới và xác nhận thẻ bảo mật.
- VS-SecureConversation: Cho phép thiết lập một nội dung chia sẻ bảo mật trên nhiều tihíng điệp được gửi đi. Mục tiêu chính của chuẩn này là cải thiện hiệu năng bằng cách gian các yêu cầu được gửi đi.
38
- WS-Federation: Định nghĩa cơ chế và cho phép thiết lập các sự toàn vẹn và hợp tác trên nhiều lĩnh vực bảo mật khác nhau, bằng cách cho phép và trao đổi một cách tin tưởng các nhận dạng, thuộc tính và xác thực.
Thông thường đối với các web service, các chuẩn này không cần thiết phái tương thích vì có quá nhiều phiên bản và nhiều cách khác nhau đế phiên dịch các chuân. Ket qua là sự ra đời của WS-I Basic Security Profile nhằm ngăn ngừa một số phiên ban nào đó của các chuẩn an ninh nhằm bảo đảm sự tương thích cho hệ thống.
□ XML và việc tấn công các web service
Trong tất cả các hệ thống phân tán đều tồn tại nguy cơ bị tấn công từ bên ngoài, ví dụ như tấn công DoS. Quá nhiều yêu cầu, hợp lệ hoặc không, có thề phá vỡ một nhà cur.g cấp dịch vụ, và sau đó các tấn công độc hại có thể được sử dụng. Do đó, người quan trị sẽ cần phải có khả năng dò ra và phản ứng với các cuộc tấn công. Tuy nhiên, mộ: số loại tấn công cũng có thế xảy ra với XML và các web service. Hãy cùng điêm qua một số ví dụ như sau:
XML bombs: XML là một ngôn ngữ thô sơ và đệ quy và trong một số trường hợp, cú
pháp của XML có thể mở rộng ra từ một số ít đến nhiều tài liệu XML. Có thế xét ví dụ
<?xml v ersio n -' 1.0"?> <!DOCTYPE xmlbomb [
<!ELEMENT data (#PCDATA)> <!ENTITY a "&b;&b;&b; "> <!ENTITY b "&c;&c;&c; "> <!ENTITY c "&d;&d;&d; "> <!ENTITY d "foo "> ]> <data>&a;</data>
v ấ i đề ở đây là đối tượng được tham chiếu đến đã mở rộng ra rất nhiều đối tượng
khcC, thậm chí là gấp 3x3 lần. Điều này có thể nhìn thấy thông qua trình duyệt: <díta>foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo
foo foo foo foo foo foo foo foo</data>
Và như vậy bây giờ sẽ có 10 sự mở rộng đến 10 thực thể. Mặc dù không có quá nhiều mã code được yêu cầu, nhưng điều này dẫn đến việc cú pháp của XML sẽ cố gang mớ rộrg đến một chuồi gồm 10.000.000.000 lần sự xuất hiện của foo, dần đến việc tiêu ton thời gian và tài nguyên của hệ thống. Thậm chí quá trình này có thể dần đến phá vỡ:hương trình.
M(t điểm cần chú ý là đây cũng là một dạng tấn công từ chối dịch vụ (DoS) mà không thể dò ra được bằng tường lửa, vì vấn đề không phải chỉ nằm ở số lượng thông điệp, mồcòn nằm ở nội dung của thông điệp. Nếu như tồn tại nguy cơ này cho hệ thống hay
ứng dụng, người phát triển nên cân nhắc sử dụng một số cách để ngăn chặn cú pháp củai XML hoặc dò ra những trường hợp này trước khi phân tích cú pháp.
XP'ath injections: là một kiểu tấn công bàng cách đấy mã độc vào mã lập trình ban
đầu. Với SQL injection, mẹo tấn công ở đây là lợi dụng các kỹ thuật nhàm ghép người sư dụng một cách trực tiếp với mã thực thi để nhằm chỉnh sửa mà nguồn ban đầu. Có thể giải thích nội dung của cách làm này bằng ví dụ sau:
Ng ười dùng nhập trực tiếp yêu cầu SQL:
SELECT city, zip, Street FROM customers WHERE ID=input
Nế u đầu vào dữ liệu của người dùng là 42, kết quả hiền thị của câu lệnh SQL sẽ là: SELECT city, zip, Street FROM customers WHERE ID=42
Đây là một kết quả đúng trả lại mã thành phố, zip code, và tên phố của mọi mục trong cơ sở dữ liệu có ID bằng 42.
Tuy nhiên hãy xét ví dụ sau:
42 UNION SELECT login, password,Y FROM user Nếu thay đối câu lệnh thành:
SELECT city, zip, Street FROM customers WHERE ID=42 UNION SELECT login, password,V FROM user
Kết quả trả về khi đó sẽ là toàn bộ login và mật khẩu từ bảng có tên tương ứng với user trong câu lệnh. Khi sử dụng XML, kỹ thuật tương tự hoàn toàn có thế sử dụng. Với Xpath, người sử dụng có thế điều hướng trong tài liệu XML. Nếu như dừ liệu đầu vào nhập trực tiếp ví dụ như đường dẫn, người dùng thậm chí có thể thao túng đường dần. Điều này dẫn đến việc thay thế nội dung tài liệu XML, cho phép thao tác với dữ liệu khác.
Xem xét ví dụ sau: một số mã nguồn sử dụng biểu thức Xpath sau:
string(//user[name/text() - user' and password/text() - pw']/accounƯtext()) to find account data in an XML database or file such as the following: <user> <name>josuttis</name> <password>secret77</password> <account>admin</account> </name> <name> </name>
Bây giờ nếu như username được thêm :' or 1=1 o r bi ểu thức Xpath sẽ trở thành: s,tring(//user[name/text( )="
or 1 = 1
40
Do biểu thức thứ hai trong ba biếu thức kểt hợp với trường thông tin true, toàn bộ ràng buộc bên trong dấu [] trở thành vô giá trị. Ket quả là, thông tin về tải khoán của người