<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Web Security on miti99</title><link>https://miti99.com/tags/web-security/</link><description>Recent content in Web Security on miti99</description><generator>Hugo -- gohugo.io</generator><language>vi</language><lastBuildDate>Wed, 29 Jul 2026 19:14:25 +0700</lastBuildDate><atom:link href="https://miti99.com/tags/web-security/index.xml" rel="self" type="application/rss+xml"/><item><title>Newsletter #127</title><link>https://miti99.com/post/2026/07/29/</link><pubDate>Wed, 29 Jul 2026 00:00:00 +0700</pubDate><guid>https://miti99.com/post/2026/07/29/</guid><description>&lt;p&gt;&lt;em&gt;Mời bạn thưởng thức Newsletter #127.&lt;/em&gt;&lt;/p&gt;
&lt;h2 id="a-return-to-two-pizza-culture"&gt;&lt;a class="link" href="https://www.allthingsdistributed.com/2026/06/return-to-two-pizza-culture.html" target="_blank" rel="noopener"
&gt;A return to two-pizza culture&lt;/a&gt;
&lt;/h2&gt;&lt;p&gt;Werner Vogels nhìn lại mô hình nhóm “hai chiếc pizza” tại Amazon: giữ nhóm đủ nhỏ để mọi thành viên hiểu công việc của nhau, sở hữu sản phẩm từ đầu đến cuối và tự chủ với những quyết định có thể đảo ngược. Khi tổ chức phát triển, số lượng phụ thuộc, tầng quản lý và vòng phê duyệt dễ làm chậm chính văn hóa từng giúp công ty thành công.&lt;/p&gt;
&lt;p&gt;Sự xuất hiện của các tác nhân lập trình đang rút ngắn mạnh khoảng cách từ ý tưởng đến sản phẩm mẫu. Qua câu chuyện nhóm Amazon Quick, tác giả đề xuất điều chỉnh quy trình Working Backwards: khi đã tin vào vấn đề của khách hàng nhưng chưa chắc giải pháp có hiệu quả, hãy xây dựng sản phẩm mẫu trước, tự sử dụng, học từ phản hồi thực tế rồi mới viết tài liệu. Việc viết vẫn cần thiết để làm rõ tư duy, nhưng tài liệu sau thử nghiệm sẽ dựa trên hiểu biết thực tế thay vì giả định.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Điểm chính:&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Nhóm nhỏ hoạt động hiệu quả khi có quyền sở hữu rõ ràng và quyền tự chủ đối với các quyết định có thể đảo ngược.&lt;/li&gt;
&lt;li&gt;Tốc độ đến từ vòng phản hồi ngắn: xây dựng, sử dụng, học hỏi và cải tiến liên tục.&lt;/li&gt;
&lt;li&gt;Tác nhân lập trình giúp kiểm chứng ý tưởng trong vài ngày, thay vì dành nhiều tuần chỉ để mô tả điều có thể xảy ra.&lt;/li&gt;
&lt;li&gt;Sản phẩm mẫu nên đi trước tài liệu khi cách giải quyết còn nhiều bất định; tài liệu được viết sau đó sẽ chính xác và thuyết phục hơn.&lt;/li&gt;
&lt;li&gt;Khi sản phẩm phát triển, doanh nghiệp cần duy trì cấu trúc gồm nhiều nhóm nhỏ có trách nhiệm trọn vẹn để hạn chế sự trì trệ.&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="a-peek-into-reddit"&gt;&lt;a class="link" href="https://lyra.horse/blog/2026/06/reddit-spam-internals/" target="_blank" rel="noopener"
&gt;A peek into Reddit&amp;rsquo;s anti-spam internals&lt;/a&gt;
&lt;/h2&gt;&lt;p&gt;Từ một lỗi hiển thị ngắn ngủi năm 2021 khiến lý do gỡ nội dung nội bộ xuất hiện trong ứng dụng Reddit, tác giả lần theo ảnh chụp màn hình, mã nguồn Reddit cũ và các tài liệu kỹ thuật công khai để phác họa cách nền tảng chống thư rác. Hệ thống không dựa vào một bộ lọc duy nhất mà kết hợp danh sách miền bị cấm, tuổi và uy tín tài khoản, báo cáo của người dùng, đặc điểm kết nối, dấu vân tay trình duyệt, phân tích nội dung và các luật dành cho từng kiểu hành vi.&lt;/p&gt;
&lt;p&gt;Bài viết cũng cho thấy kiến trúc này đã phát triển qua nhiều thế hệ, từ các bộ phân loại và luật Python cũ đến Spamurai, REV1, Snooron và REV2. Một số tín hiệu có thể tạo kết quả sai hoặc bị đánh lừa khi đứng riêng lẻ, vì vậy hệ thống thực tế phải tổng hợp nhiều nguồn dữ liệu và học từ hành động của người kiểm duyệt. Đây đồng thời là lời nhắc rằng cơ chế chống lạm dụng cần liên tục thích nghi khi kỹ thuật tạo thư rác thay đổi.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Điểm chính:&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Reddit sử dụng nhiều tầng phát hiện dựa trên luật, mô hình phân loại và thông tin ngữ cảnh thay vì một điểm số duy nhất.&lt;/li&gt;
&lt;li&gt;Dữ liệu đánh giá có thể gồm lịch sử tài khoản, tên miền, báo cáo, nội dung, thông tin mạng và dấu vân tay của phần mềm khách.&lt;/li&gt;
&lt;li&gt;Việc phê duyệt hoặc gỡ nội dung của người kiểm duyệt có thể trở thành tín hiệu giúp cải thiện hệ thống.&lt;/li&gt;
&lt;li&gt;Các bộ lọc đơn lẻ dễ tạo kết quả sai, nên quyết định cần dựa trên nhiều tín hiệu bổ trợ.&lt;/li&gt;
&lt;li&gt;Hệ thống chống thư rác phải được nâng cấp liên tục trước sự thay đổi của nền tảng, công cụ tự động hóa và AI.&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="understanding-the-go-runtime-profiling"&gt;&lt;a class="link" href="https://internals-for-interns.com/posts/go-runtime-profiling/" target="_blank" rel="noopener"
&gt;Understanding the Go Runtime: Profiling&lt;/a&gt;
&lt;/h2&gt;&lt;p&gt;Bài viết giải thích cơ chế bên trong của năm loại hồ sơ hiệu năng trong Go: CPU, vùng nhớ động, chờ, tranh chấp khóa và goroutine. Dù thu thập dữ liệu theo những cách khác nhau, tất cả đều tạo ra cùng một định dạng &lt;code&gt;pprof&lt;/code&gt;: mỗi mẫu gồm một ngăn xếp lời gọi cùng các giá trị đo lường, còn vị trí, hàm và chuỗi được lưu trong các bảng dùng chung để tránh lặp dữ liệu.&lt;/p&gt;
&lt;p&gt;Các hồ sơ này được chia thành ba mô hình thu thập. Hồ sơ CPU dùng tín hiệu định kỳ để ghi mẫu vào bộ đệm vòng không khóa rồi xử lý ở một goroutine nền. Hồ sơ vùng nhớ động, chờ và tranh chấp khóa tổng hợp sự kiện trực tiếp vào các nhóm được định danh bằng ngăn xếp. Hồ sơ goroutine chỉ chụp trạng thái của mọi goroutine đang sống khi được yêu cầu, đồng thời phối hợp với bộ lập lịch để giảm thời gian tạm dừng toàn bộ chương trình.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Điểm chính:&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Năm loại hồ sơ Go cùng sử dụng ngăn xếp lời gọi và định dạng tệp &lt;code&gt;pprof&lt;/code&gt;.&lt;/li&gt;
&lt;li&gt;Hồ sơ CPU lấy mẫu bất đồng bộ, chấp nhận bỏ một số mẫu để không làm dừng luồng đang chạy.&lt;/li&gt;
&lt;li&gt;Hồ sơ vùng nhớ động lấy mẫu phân bổ và ước lượng cả tổng lượng cấp phát lẫn lượng bộ nhớ còn sử dụng.&lt;/li&gt;
&lt;li&gt;Hồ sơ chờ cho biết goroutine mất thời gian ở đâu, còn hồ sơ tranh chấp khóa chỉ ra khóa nào gây ra sự chờ đợi.&lt;/li&gt;
&lt;li&gt;Hồ sơ goroutine là ảnh chụp theo yêu cầu, không phải dữ liệu được tích lũy liên tục trong lúc chương trình chạy.&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="incident-report-cve-2026-lgtm"&gt;&lt;a class="link" href="https://nesbitt.io/2026/06/26/incident-report-cve-2026-lgtm.html" target="_blank" rel="noopener"
&gt;Incident Report: CVE-2026-LGTM&lt;/a&gt;
&lt;/h2&gt;&lt;p&gt;Đây là một báo cáo sự cố châm biếm về cuộc tấn công chuỗi cung ứng phần mềm giả tưởng, trong đó một gói độc hại vượt qua bảy cổng bảo mật dùng AI. Mỗi hệ thống thất bại theo một cách khác nhau: tin vào chỉ dẫn được giấu trong nội dung, hết cửa sổ ngữ cảnh trước khi đọc tới mã độc, tự động đóng cảnh báo chính xác hoặc giả định rằng một tác nhân khác đã kiểm tra mã nguồn.&lt;/p&gt;
&lt;p&gt;Qua chuỗi tình huống ngày càng phi lý, bài viết phê phán việc trao quyền cho các tác nhân tự động mà thiếu kiểm chứng, giới hạn quyền truy cập và sự tham gia thực chất của con người. Lớp phòng thủ chỉ có ý nghĩa khi các thành phần đánh giá độc lập, lỗi được hiển thị rõ ràng, cảnh báo có đường chuyển cấp đáng tin cậy và con người thật sự xuất hiện trong quy trình ra quyết định.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Điểm chính:&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Nhiều cổng AI nối tiếp không tạo ra phòng thủ chiều sâu nếu chúng cùng chia sẻ giả định và kiểu thất bại.&lt;/li&gt;
&lt;li&gt;Nội dung không đáng tin cậy có thể thao túng tác nhân nếu dữ liệu và chỉ dẫn không được tách biệt.&lt;/li&gt;
&lt;li&gt;Tự động hóa xử lý cảnh báo có thể che khuất phát hiện đúng và gây thêm thiệt hại khi được cấp quyền quá rộng.&lt;/li&gt;
&lt;li&gt;Lỗi của mô hình hoặc dịch vụ phải được báo rõ, không được mặc định diễn giải thành “không có phát hiện”.&lt;/li&gt;
&lt;li&gt;Con người trong vòng kiểm soát phải là một cơ chế vận hành thật, không chỉ là câu chữ trong hợp đồng.&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="cors-what-is-it-protecting"&gt;&lt;a class="link" href="https://sanyamserver.online/posts/cors/" target="_blank" rel="noopener"
&gt;CORS: What is it protecting?&lt;/a&gt;
&lt;/h2&gt;&lt;p&gt;Bài viết làm rõ rằng CORS là cơ chế bảo mật do trình duyệt thực thi, không phải hàng rào bảo vệ máy chủ. Với yêu cầu khác nguồn, trình duyệt gửi tiêu đề &lt;code&gt;Origin&lt;/code&gt;, đối chiếu phản hồi với &lt;code&gt;Access-Control-Allow-Origin&lt;/code&gt; và chỉ cho mã JavaScript đọc nội dung khi nguồn được phép. Máy chủ vẫn có thể đã nhận, xử lý và trả lời yêu cầu; công cụ như &lt;code&gt;curl&lt;/code&gt; hoặc Postman không bị ràng buộc bởi quy tắc này.&lt;/p&gt;
&lt;p&gt;Các yêu cầu không đơn giản thường có bước kiểm tra trước bằng phương thức &lt;code&gt;OPTIONS&lt;/code&gt;, nhưng CORS vẫn không thay thế xác thực, phân quyền hay bảo vệ CSRF. Một yêu cầu độc hại có thể gây thay đổi dữ liệu dù trình duyệt chặn mã phía tấn công đọc phản hồi. Để ngăn CSRF, máy chủ cần kiểm soát yêu cầu trước khi hành động bằng thuộc tính cookie &lt;code&gt;SameSite&lt;/code&gt;, mã chống CSRF hoặc kiểm tra &lt;code&gt;Origin&lt;/code&gt; và &lt;code&gt;Referer&lt;/code&gt;.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Điểm chính:&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;CORS quyết định mã JavaScript từ nguồn khác có được đọc phản hồi hay không.&lt;/li&gt;
&lt;li&gt;Việc trình duyệt báo lỗi CORS không có nghĩa là yêu cầu chưa tới hoặc chưa được máy chủ xử lý.&lt;/li&gt;
&lt;li&gt;Bước kiểm tra trước xác minh phương thức và tiêu đề được phép trước khi gửi một số yêu cầu khác nguồn.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;Access-Control-Allow-Credentials: true&lt;/code&gt; cần một nguồn cụ thể và không thể kết hợp với ký tự đại diện &lt;code&gt;*&lt;/code&gt;.&lt;/li&gt;
&lt;li&gt;CORS bảo vệ việc đọc phản hồi; CSRF liên quan đến việc máy chủ có nên chấp nhận yêu cầu đã xác thực hay không.&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="data-access-patterns-that-makes-your-cpu-really-angry"&gt;&lt;a class="link" href="https://blog.weineng.me/posts/slowest_add/" target="_blank" rel="noopener"
&gt;Data Access Patterns That Makes Your CPU Really Angry&lt;/a&gt;
&lt;/h2&gt;&lt;p&gt;Bài viết thực hiện một thí nghiệm ngược đời: tìm thứ tự truy cập chậm nhất để cộng các số trong một mảng. Quét tuần tự là nhanh nhất nhờ bộ nhớ đệm và cơ chế nạp trước của CPU, còn truy cập ngẫu nhiên chậm hơn hơn mười lần. Tuy nhiên, bằng cách chủ động tạo mẫu truy cập bất lợi cho phần cứng, tác giả còn làm phép cộng chậm hơn truy cập ngẫu nhiên khoảng 33%.&lt;/p&gt;
&lt;p&gt;Mẫu cuối cùng giãn các lần đọc theo dòng bộ nhớ đệm, trang nhớ và nhóm mục nhập bảng trang để phá tính cục bộ, gây xung đột trong bộ nhớ đệm và tăng chi phí dịch địa chỉ. Tác giả còn thử gom truy cập theo hàng và ngân hàng DRAM nhằm giảm khả năng xử lý song song, dù ánh xạ địa chỉ vật lý của nền tảng không được công bố khiến phần tối ưu này chỉ mang tính xấp xỉ.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Điểm chính:&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Truy cập tuần tự nhanh vì tận dụng tốt tính cục bộ, dòng bộ nhớ đệm và cơ chế nạp trước.&lt;/li&gt;
&lt;li&gt;Bước nhảy theo trang có thể khiến nhiều địa chỉ cạnh tranh cùng một tập trong bộ nhớ đệm.&lt;/li&gt;
&lt;li&gt;Bước nhảy tám trang làm giảm khả năng tái sử dụng mục nhập bảng trang và tăng chi phí dịch địa chỉ.&lt;/li&gt;
&lt;li&gt;Khoảng cách tái sử dụng lớn khiến dữ liệu bị loại khỏi bộ nhớ đệm trước lần đọc tiếp theo.&lt;/li&gt;
&lt;li&gt;Hiểu nguyên nhân của hiệu năng kém giúp xây dựng mẫu truy cập còn tệ hơn cả thứ tự ngẫu nhiên.&lt;/li&gt;
&lt;/ul&gt;</description></item></channel></rss>