- Cloudflare đã sử dụng Claude LLM của Anthropic để phát triển một thư viện OAuth mới, đồng thời cũng công khai các prompt
- Cấu trúc mã của thư viện khá gọn gàng, nhưng còn nhiều điểm đáng tiếc về mặt kiểm thử và xác minh bảo mật
- Trong CORS và việc triển khai một số chuẩn xác thực, đã phát hiện các lựa chọn phi tiêu chuẩn hoặc rủi ro
- Phần triển khai mật mã có những ưu điểm, nhưng cũng bộc lộ lỗi bảo mật nghiêm trọng và sự hiểu nhầm về giao thức
- Tự động sinh mã dựa trên LLM có thể hữu ích, nhưng để đạt mức bảo mật cho môi trường thực tế, vẫn bắt buộc cần chuyên gia rà soát kỹ lưỡng
Tổng quan về thư viện OAuth của Cloudflare
- Cloudflare đã dùng Claude LLM của Anthropic để tự động viết phần lớn thư viện OAuth provider
- Đầu ra của Claude đã được các kỹ sư giàu kinh nghiệm của Cloudflare rà soát về bảo mật và mức độ tuân thủ tiêu chuẩn, đồng thời quá trình tương tác với AI cũng được công khai minh bạch trong lịch sử commit
- Sau bản triển khai ban đầu, chất lượng tiếp tục được cải thiện thông qua các prompt bổ sung cho Claude và việc xem xét kết quả đầu ra
- Cloudflare cũng nêu rõ rằng họ không phụ thuộc hoàn toàn vào AI mà nhấn mạnh việc đối chiếu chéo với tài liệu RFC và review từ các chuyên gia nòng cốt
Ấn tượng ban đầu của chuyên gia và phân tích mã
- Mang đặc trưng của cách lập trình với LLM, mã được dồn vào một tệp duy nhất, nhưng cấu trúc nhìn chung nhất quán và có tương đối ít chú thích thừa
- Có kiểm thử chức năng, nhưng chưa đạt đến mức cần thiết cho một dịch vụ xác thực quan trọng như OAuth
- Có thể thấy dấu hiệu thiếu kiểm tra các yêu cầu bắt buộc (MUST/MUST NOT) và việc xác thực tham số còn lỏng lẻo
Các lo ngại về bảo mật và phần diễn giải của người dịch
1. Vấn đề chính sách CORS ("YOLO CORS")
- Phát hiện thiết lập header CORS cho phép gần như mọi origin, khiến chính sách same-origin trên thực tế gần như bị vô hiệu hóa
- Đây là phần được kỹ sư Cloudflare con người trực tiếp quyết định, không phải do LLM
- Dù tính năng credentials chưa được bật nên nguy cơ đe dọa bảo mật trình duyệt ở mức nghiêm trọng là không cao, nhưng tính rõ ràng về nguyên nhân và mục đích vẫn còn thiếu
2. Không áp dụng các header bảo mật tiêu chuẩn
- Trong phản hồi HTTP, tồn tại tình trạng không áp dụng các header bảo mật quan trọng như X-Content-Type-Options: nosniff và HTTP Strict Transport Security
- Do đặc tính của JSON API, mức cần thiết của một số header có thể thấp hơn, nhưng xét trên phương diện phòng ngừa lỗ hổng phía client/trình duyệt thì vẫn rất nên áp dụng
3. Dấu hiệu chưa nắm vững chuẩn OAuth
- Để hỗ trợ public client, thư viện đã triển khai implicit grant, vốn đã bị loại bỏ trong OAuth 2.1
- Thực tế, chức năng này hoàn toàn có thể được thay thế bằng PKCE hoặc nới lỏng CORS
- Có vẻ Claude đã gợi ý implicit grant, nhưng ở bước cấp token thực tế thì lại không xác minh đúng cách
- Xử lý Basic Auth còn thiếu sót: OAuth yêu cầu một kiểu URL encoding riêng, nhưng phần này đã bị bỏ qua
- Điều này có thể tạo ra một lỗi bảo mật phụ khi client secret chứa dấu hai chấm
- Tuy vậy, thư viện này tự tạo client ID/secret nên có cấu trúc cho phép kiểm soát định dạng
4. Vấn đề bảo mật trong mã tạo token ID
- Cách tạo chuỗi ngẫu nhiên cho token ID có độ lệch thống kê (biased)
- Việc giảm entropy có thể khiến tấn công dễ hơn, dù mối đe dọa thực tế là khá hạn chế
- Trái với tuyên bố rằng mọi dòng mã đều đã được chuyên gia review, lỗi này vẫn tồn tại nguyên vẹn trong commit ban đầu
- Lịch sử có việc một lập trình viên trực tiếp commit 21 lần vào nhánh chính ngay trong ngày đầu tiên, cho thấy khả năng thiếu quy trình review có hệ thống
Chức năng mật mã và ví dụ về tương tác với LLM
- Kiến trúc mã hóa kho lưu token được con người dẫn dắt, còn Claude hỗ trợ phần triển khai
- Thiết kế áp dụng cách mã hóa props theo từng token và bọc khóa đối xứng cho mỗi token
- Khi Claude đề xuất một thiết kế sai ở giữa quá trình, kỹ sư đã nêu rõ chủ đích và mục tiêu bảo mật để chỉnh lại
- Ví dụ: chỉ ra lỗ hổng khi dùng hash SHA-256 làm wrapping key, sau đó đổi sang cách dựa trên HMAC
- Với đề xuất PBKDF2, kỹ sư chỉ ra sự kém hiệu quả về hiệu năng và điều chỉnh sang dùng khóa HMAC 32 byte
- Quá trình này cho thấy rất rõ sự cần thiết của kiến thức miền ở mức cao khi làm việc với AI
- Người không chuyên thậm chí có thể không nhận ra được các lỗi chí mạng
Tổng kết và hàm ý
- Dù mới là phiên bản đầu tiên, mức độ hoàn thiện nhìn chung là tạm ổn, nhưng vẫn quá rủi ro để áp dụng ngay vào dịch vụ thực tế
- Việc phát triển một OAuth provider về bản chất đòi hỏi kiểm chứng bảo mật và chức năng cực kỳ khó khăn
- Ở các công ty lớn, thông thường sẽ có hàng trăm nghìn bài test tự động cùng các lớp kiểm tra bảo mật nhiều tầng
- Đây không phải lĩnh vực có thể áp dụng lập trình tự động dựa trên LLM một cách “dễ dàng”
- Lịch sử commit của dự án cho thấy khá thú vị về mức độ mà LLM có thể hỗ trợ như một công cụ phụ trợ
- Tuy vậy, một số lỗi lại là kiểu sai sót mà cả LLM lẫn con người đều thường mắc phải, và cũng thường thấy tương tự trong các câu trả lời trên Stack Overflow hay cộng đồng sẵn có
- Với những vùng mã đòi hỏi sự cẩn trọng và tỉ mỉ, cả AI lẫn con người đều cần chú ý ở mức rất chi tiết
- Nếu muốn dùng LLM để review mã hoặc tin tưởng vào kết quả của nó, kinh nghiệm triển khai trực tiếp và tư duy System 2 là điều bắt buộc
- Với các tác vụ đơn giản hoặc không cốt lõi, hoàn toàn có thể giao cho LLM; nhưng với những hệ thống quan trọng liên quan đến xác thực hay bảo mật, thiết kế và triển khai do chuyên gia dẫn dắt vẫn là lựa chọn phù hợp hơn
2 bình luận
Cloudflare công bố cách họ xây dựng OAuth cùng Claude và công khai toàn bộ prompt
Ý kiến Hacker News
Trường hợp này cho thấy rất rõ rằng khi tương tác với LLM thì cần rất nhiều kiến thức miền. Ví dụ, một lập trình viên bình thường có thể không nhận ra “lỗi nghiêm trọng” mà Claude tự bịa ra ở giữa chừng. Việc cảm thấy kỳ lạ khi nó đổi sang PBKDF2 cũng là nhờ chuyên môn miền. Kết luận của tôi là để dùng LLM hiệu quả thì cần một reviewer giỏi và một “người dẫn dắt”. Nếu bạn biết về chủ đề đó không hơn LLM là bao, thì chỉ nên dùng ở mức độ thấp, hoặc phải có đủ thời gian để xác minh toàn bộ đầu ra
Tôi tự hỏi trong môi trường mới này thì các chuyên gia miền sẽ xuất hiện từ đâu. Rốt cuộc ai sẽ trở thành người hiểu sâu đến mức đó?
Mỗi khi nghe ý kiến kiểu “chỉ dùng LLM ở lĩnh vực mình không rành, còn chuyên gia thì tự code”, tôi lại thấy khó hiểu. Ngược lại, càng là chuyên gia thì càng có thể rà soát đầu ra của LLM chính xác hơn, và tôi càng mô tả điều mình muốn theo cách gần với chuyên gia miền thì kết quả càng tốt. Xét theo một nghĩa nào đó thì điều này khá hiển nhiên (vì LLM là cỗ máy sinh văn bản theo thống kê)
LLM có xu hướng rất dễ thêm giá trị mặc định, xử lý ngoại lệ, và đủ loại đường vòng. Vì thế nó dễ tạo ra đoạn mã trông như chạy được nhưng thực tế có vấn đề hoặc sắp thất bại. Tôi đã cố nhấn mạnh điểm này nhiều lần trong
CLAUDE.mdmà kết quả như vậy vẫn thường xuyên xuất hiệnTôi đã dùng LLM để xử lý phần lớn công việc triển khai k8s. Nó cho ra kết quả chạy được rất nhanh, nhưng tôi luôn phải liên tục nhắc nó dùng secret và không commit thông tin xác thực dưới dạng plain text. Những sai sót như vậy thực sự rất nguy hiểm. Trong các tutorial phục vụ học tập, người ta thường lược bỏ bảo mật để tập trung vào phần cơ bản, và có lẽ vì dữ liệu huấn luyện của LLM có quá nhiều ví dụ như thế nên nó mới sinh ra đầu ra kiểu này
Tôi kỳ vọng theo thời gian, các công cụ code AI sẽ có thể tự nghiên cứu kiến thức miền. Một số công cụ “AI research” hiện nay đã rất giỏi việc này, nhưng vẫn chưa được tích hợp tử tế với công cụ lập trình. Việc nghiên cứu có thể tham chiếu không chỉ Internet công khai mà còn cả kiến thức miền trong tài liệu nội bộ công ty. Tuy nhiên, một phần kiến thức chỉ nằm trong đầu con người nên người dùng vẫn phải tự truyền đạt
Gần đây tôi đã viết một Kafka consumer với sự hỗ trợ của AI để thực hiện di chuyển dữ liệu. Hiệu quả dùng AI đạt mức cao nhất trong kiểu dự án ngắn hạn, viết mới từ đầu như thế này, khi tôi khá rành ngôn ngữ (go) nhưng đã lâu không dùng lại. Vì toàn bộ dữ liệu đổ vào một topic nên tôi đã triển khai xử lý song song khá phức tạp để đảm bảo hiệu năng. Nhìn chung tôi có cảm giác AI giúp tăng tốc khoảng gấp 2 lần. Đặc biệt, những lúc thỉnh thoảng quên cú pháp go, việc hỏi AI ngay thay vì đi tìm kiếm rất hữu ích. Nhưng vẫn có ít nhất 4 bug tiềm ẩn (ngoài ra còn nhiều bug hiển nhiên hơn). Nếu không quen Kafka hay multithreading thì có lẽ tôi đã đẩy nó thẳng lên production. Với dự án lớn/dài hạn thì mức cải thiện vào khoảng 10~20%. Với các model mới nhất thì xu hướng hiện tại là vậy. Xét tổng thể, điều này giống với mức tăng năng suất khi chuyển sang ngôn ngữ có quản lý bộ nhớ. Nó rất xa với viễn cảnh PM thay thế lập trình viên. Ngược lại, điều tôi thực sự lo là nếu những lập trình viên tầm trung kiểu “siêu bão kỹ thuật” được AI tăng hiệu suất lên 10 lần thì họ có thể trở nên nguy hiểm hơn vì không phát hiện hoặc xử lý được các bug tinh vi. Tôi thấy kỹ sư senior/staff sẽ không thể chịu nổi lượng review đổ về. Và tôi cũng lo rằng quá trình trưởng thành từ junior lên senior sẽ trở nên mong manh hơn. Vốn dĩ lập trình viên copy-paste đã là vấn đề, và AI càng củng cố mô thức đó. Cuối cùng thị trường có thể sẽ tự điều chỉnh, nhưng tôi vẫn bất an vì chuyện đó có thể mất hàng chục năm
Những bug do AI tạo ra thực sự rất tinh vi. Tôi cũng từng cho AI viết code đa luồng rồi thật sự đưa bug tinh vi đó vào production. Dù có review và test thì mức độ tập trung vẫn không bằng khi tự tay viết. Trước mắt tôi cảm thấy cần phải đối xử với code do AI viết theo hướng kiểm tra trước các bug phổ biến và chỉ dùng trong những khu vực không gây tác động nghiêm trọng nếu có sự cố
Tôi cũng cảm nhận mức cải thiện khoảng 10~20% trong các “công việc quan trọng”. Đó đúng là thay đổi thật, nhưng không làm thay đổi bản chất của phát triển phần mềm. Rốt cuộc đây chỉ là một lần nữa xác nhận luận điểm “No Silver Bullet” của Brooks
Tôi cũng đồng ý với luận điểm về “cơn bão kỹ thuật hạng trung”. Đặc biệt trong ngành tư vấn, thực tế là những người kỳ cựu thường bị xem là có giá trị không tương xứng với chi phí. Trước đây tôi cũng thuộc nhóm làm việc nhanh, rồi về sau phải rất vất vả giải thích cho PM không chuyên về những điểm yếu của các giải pháp ngắn hạn. Các công ty IT lớn sẽ phát hiện kiểu vấn đề này nhanh hơn, nhưng trong thực tế, code xử lý dữ liệu tài chính hay y tế lại thường do lực lượng hợp đồng ngắn hạn giá rẻ viết ra. Tình trạng đó đã là vấn đề từ trước khi có LLM. Giờ đây có lẽ là thời kỳ còn khó khăn hơn nhiều với các lập trình viên làm việc trong môi trường nhạy cảm về bảo mật
Bạn nói đã phát hiện bug tinh vi trong code được sinh ra, vậy sẽ thế nào nếu dùng test code do AI tạo ra để tự động phát hiện những bug đó? Tất nhiên bản thân test code cũng có thể có bug, nhưng tôi hình dung ra một kịch bản tương lai nơi ta chỉ tập trung rà soát kết quả test hơn là chính đoạn code được sinh ra
Bạn nói đến xử lý song song phức tạp, nhưng chẳng phải đó là dạng vấn đề có thể giải quyết bằng partition và consumer-group sao?
Nhìn những người tích cực tin tưởng LLM rồi “lao xuống vực” mà dựa dẫm vào nó một cách vô phê phán để làm việc, tôi thật sự thấy bức bối. Phụ thuộc hoàn toàn vào một hộp đen để làm việc rồi giao luôn cả phần xác minh cho nó là rất nguy hiểm. Hơn nữa đây còn là một cấu trúc tiêu tốn năng lượng khổng lồ, nên cũng bị dùng như cái cớ để thay thế con người. Tôi thật lòng không tin môi trường như vậy khiến cuộc sống tốt hơn gấp 10 lần
Khi so sánh giữa việc tự phát triển với quá trình xác minh sản phẩm do người khác tạo ra (đặc biệt là code do LLM sinh ra), con người thường có xu hướng bị đánh lừa bởi vẻ ngoài hợp lý và chấp nhận vấn đề một cách kém phê phán hơn. “Diện mạo” của code cũng ảnh hưởng lớn đến việc tìm bug. Muốn kiểm chứng điều này thì có thể cố tình cài bug vào code rồi làm thử nghiệm xem reviewer có tìm ra không. Khi tự tay triển khai một thứ gì đó, ta suy nghĩ chậm hơn nhiều, kỹ lưỡng hơn, và chú ý đến chi tiết hơn (nhờ vậy cũng phát hiện những bug không ngờ tới). Vì thế mà người ta vẫn khuyên rằng để học thì cách tốt nhất là tự viết một “phiên bản đồ chơi” của công cụ. Đây là câu chuyện gắn với cấu trúc nhận thức của con người
Bài viết nói là không có nhiều chú thích thừa, nhưng trong code thực tế lại có những chú thích vô nghĩa như
// Get the Origin header from the requestKiểu chú thích này là bằng chứng lộ liễu cho thấy có dùng LLM, vô nghĩa nên tôi luôn xóa
Với con người thì loại chú thích này không có ích, nhưng tôi đoán với LLM, việc chức năng của đoạn code bên dưới được mô tả kèm bằng ngôn ngữ tự nhiên có thể đóng vai trò như một kiểu đá Rosetta giúp nó hiểu hơn. Đổi lại là tốn thêm token, nhưng tôi cũng muốn kiểm chứng xem liệu LLM có chỉnh sửa tốt hơn trên code bị chú thích quá mức hay không
Chia sẻ từ kinh nghiệm là Claude có xu hướng viết những chú thích thừa, vô dụng và lặp lại như vậy cực kỳ thường xuyên
Điều tôi muốn đề xuất là đóng băng một branch của code, rồi dùng các AI để một bên cố tạo và che giấu lỗ hổng, còn bên kia đóng vai trò tìm và sửa chúng, như một trận chiến. Tức là áp dụng quá trình tiến hóa kiểu cờ vua vào phát triển phần mềm
Tôi chính là tác giả của thư viện này (chính xác hơn là người viết prompt). Tuy không bằng Neil, tôi cũng có chút chuyên môn về OAuth, và tôi thật sự rất vui vì anh ấy đã review code. Có một hiểu lầm liên quan đến “YOLO CORS”: đây không phải lỗi ngớ ngẩn của người mới. Các thiết lập CORS này được cân nhắc kỹ và cố ý làm vậy. Tôi chỉ vô hiệu hóa CORS ở các endpoint OAuth API (trao đổi token, đăng ký client) và các endpoint API yêu cầu OAuth bearer token. Vì các endpoint này không được xác thực bằng thông tin định danh của trình duyệt (cookie, v.v.), nên theo tôi CORS thực tế không bảo vệ được gì ở đây. Bản chất của CORS là một lớp bảo mật ngăn việc tự động đính kèm thông tin xác thực, còn bearer token thì phải do client tự gắn vào một cách tường minh nên vẫn an toàn cả trong môi trường cross-origin. Thực ra từ trước tôi đã từng tranh luận với người viết spec CORS và luôn cho rằng muốn thực sự an toàn thì phải dùng bearer token thay vì thông tin xác thực của trình duyệt. Mặt khác, về chỉ trích cho rằng việc tạo token ID kém hiệu quả, tôi không cho là nó tới mức “nghiêm trọng”. Bản thân tính bảo mật không có vấn đề, và thuật toán cũng có thể thay đổi tự do về sau. Còn việc có 21 commit được một người đưa lên
maintrong cùng một ngày là do git history bị rewrite nên GitHub hiển thị ngày tháng méo mó. Cảm ơn lời khen về phần triển khai mật mã. Đó không phải do AI tạo ra mà là nhờ chỉ dẫn thiết kế rất cụ thể của tôiBạn nói là “vô hiệu hóa CORS header ở OAuth API”, nhưng trên thực tế là đang thiết lập CORS header theo cách làm vô hiệu hóa các quy tắc CORS. Trong ngữ cảnh thì cũng đủ hiểu, nhưng bổ sung vậy để tránh nhầm lẫn
Tôi tò mò không biết Cloudflare có kế hoạch dùng thư viện này trong vận hành thực tế hay không
Tôi thấy lo khi nghĩ rằng những lỗi sai y hệt cũng đầy rẫy trong các câu trả lời nổi tiếng trên Stack Overflow, và Claude hẳn đã học từ những nơi như vậy. Điều đáng sợ hơn cả lỗ hổng bảo mật hay sai sót riêng lẻ là kho tri thức chung của xã hội có thể bị cố định ở mức các câu trả lời Internet phổ biến từ trước thời LLM
Nhìn vào chuyện ForgeRock có hàng trăm lỗi bảo mật trong triển khai OAuth, dù đã có hàng trăm nghìn bài test tự động, threat modeling, SAST/DAST cấp cao nhất và review chuyên gia, tôi lại càng cảm nhận rõ OAuth khó đến mức nào. Có người còn gọi nó là dạng triển khai “cháy bãi rác”. Bản thân tôi thì chưa từng đọc spec hay tự triển khai
Mỗi lần có liên quan đến triển khai OAuth, tôi luôn có cảm giác nó phức tạp một cách khủng khiếp
OAuth thực sự rất phiền phức và có quá nhiều ngóc ngách đặc thù
Thực ra code mới viết thì lúc nào cũng sẽ có bug. Càng phức tạp càng chắc chắn như vậy. Vì thế doanh nghiệp mới cố dùng code và công cụ “battle tested” đã được chứng thực ngoài thực địa. Bỏ qua chuyện đùa, cách Anthropic dùng AI tạo sinh của chính họ vào code nội bộ theo hướng thực dụng khá thú vị. Tôi tự hỏi sau này họ có dùng nó cho cả MCP authentication API hay không
“Hàng trăm nghìn bài test” nghe như kiểu chỉ có thể là tăng trưởng về số lượng đơn thuần, hoặc là do LLM tạo ra nguyên mớ. Tôi cũng tò mò không biết ai thực sự quản lý đống đó
Tôi tò mò liệu việc mọi người commit prompt của mình vào git có trở thành xu hướng phổ biến hay không, hay chỉ mang tính showcase