Có một chuyện gì đó đang xảy ra đối với thế giới web. Khiến người dùng không hài lòng. Và nguồn gốc của sự bất ổn đó bắt nguồn từ các cộng đồng lập trình của chúng ta.
Khởi đầu của sự bất ổn là một số lượng lớn các lập trình viên công khai đặt câu hỏi về nền tảng web. Đây là một bài viết cụ thể và cuộc thảo luận về chủ đề trên (các nguồn đều bằng tiếng Anh). Nếu bạn là một người quan tâm đến sự phát triển của web, hẳn bạn đã đọc ít nhiều các câu chuyện thú vị trong năm nay về tình trạng phát triển web. Tuy nhiên bài viết này hoàn toàn khác với các bài viết liệt kê ở trên.
Tôi muốn tìm hiểu về cách các đối thủ cạnh tranh trên chiến trường web, làm thế nào để có thay thế đối phương và sát nhập chúng thành một, ít nhất là lĩnh vực viết ứng dụng. Tuy web gặp vấn đề trong việc tìm cách phân phối các dữ liệu, nhưng chuyện đó không quá nghiêm trọng.
Trong bài này, tôi sẽ xem xét các vấn đề một cách sâu sắc, tuy không thể sửa chữa được nền tảng web. Đơn giản vì bạn sẽ không thể khắc phục vấn đề nếu bạn không phân tích chúng trước. Tôi cũng sẽ làm một thí nghiệm nhỏ về việc, tại sao bây giờ chúng ta mới đề cập đến những vấn đề này một cách nghiêm túc, mặc dù chúng không thực sự mới.
Tại sao web phải “chết”
Ứng dụng web. Chúng là như thế nào? Tôi có thể liệt kê tất cả các vấn đề thường gặp với chúng, nhưng đây là 2 điều đáng lưu ý nhất
Quá trình phát triển web diễn ra rất chậm từ những năm 1990.
Ứng dụng trên web không thể bảo đảm.
Đây là một bài blog về Flux, công trình nghiên cứu mới nhất của Facebook. Tác giả chỉ ra rằng Flux đã tái tạo lại mô hình lập trình được sử dụng bởi Windows 1.0, phát hành năm 1985. Microsoft đã sử dụng mô hình này bởi vì nó thích hợp cho các máy tính siêu chậm.
Đó là một trong những lý do khiến React / Flux làm chậm tốc độ render web. Có một sự thật rằng những kết quả cuối cùng mà người dùng thực sự thấy được cũng chính là những gì mà một người dùng Windows đã có thể nhìn thấy cách đây 20 năm:
Tất nhiên, tốc độ phân giải của màn hình ngày càng cao. Nền màu xám của thanh công cụ đã thay đổi. Tuy nhiên, UI mà bạn nhìn thấy ở trên khá giống với UI mà bạn thấy dưới đây:
Ngay cả các icon cũng giống nhau! Windows 98 đã mang đến một xu hướng mới cho các icon bằng phẳng, màu xám với nhiều bước đệm đến với một nền tảng trước đây đầy màu sắc.
Trong khi Office 2000 chỉ cần một CPU 75 Mhz và 32MB bộ nhớ RAM, thì Google Docs ở trên phải sử dụng CPU 2.5Ghz và với số RAM hơn 10 lần.
Nhưng nếu đổi lại chúng tôi có được năng suất nhanh hơn 10 lần hoặc có thêm 10 tính năng khác thì có lẽ điều đó cũng chấp nhận được. Nhưng không, các nền tảng phát triển vào năm 1995 sẽ có tất cả những điều sau, tương đương với những yêu cầu của chúng:
Một thiết kế UI trực quan với các ràng buộc về bố cục và ràng buộc dữ liệu.
- Hỗ trợ tốt cho các phần mềm đa ngôn ngữ. Bạn có thể kết hợp native code và script language.
- Output cho các chương trình nhị phân hiệu quả mà họ có thể chạy chỉ cần một vài megabyte RAM.
- Hỗ trợ dữ liệu dạng đồ thị, theme, đồ họa 3D, lập trình socket, debug …
Những tính năng này chỉ được đưa lên nền tảng web trong vài năm qua và thường theo những cách khá sơ sài. Các ứng dụng web không thể sử dụng socket thực, vì vậy các server phải được thay đổi để hỗ trợ các “web socket”. Những điều cơ bản như các thành phần UI là thì “tan nát”, không có web IDE đáng nói có thể mix các ngôn ngữ lập trình khác nhau … tuy nhiên, bạn có thể chuyển sang JavaScript.
Một lý do khiến các lập trình viên viết ứng dụng web đáp ứng mong đợi của người dùng trên web là rất thấp. Vì ứng dụng dành cho Windows 95 được kỳ vọng có các icon, kéo và thả, undo, liên kết tập tin, phím tắt, hoạt động dưới nền tốt … và thậm chí làm việc ngoại tuyến! Nhưng đó chỉ là những ứng dụng cơ bản. Phần thực sự ấn tượng là nhúng được bên trong các tài liệu Office, hoặc mở rộng trên Explorer, hoặc cho phép bản thân nó được mở rộng với các plugin độc lập. Các ứng dụng web thường không thực hiện những việc này.
Tất cả những điều này. Khiến tôi cảm thấy năng suất hơn rất nhiều khi viết ứng dụng dành cho desktop (thậm chí bao gồm cả các loại phí khác bạn phải trả, như tạo icon cho file của bạn). Tôi thích sử dụng chúng. Và từ các cuộc thảo luận trên cộng đồng, tôi cảm thấy rằng không chỉ mình nghĩ thế.
Tôi nghĩ rằng web gặp những vấn đề trên vì trong khi HTML như là một document platform, bắt đầu với một số triết lý design và toolset. Vì vậy, những điều cơ bản như sự liên kết các tập tin không tồn tại, nhưng HTML5 có thể xem video trực tuyến, bởi vì Google muốn làm cho Hangouts và ưu tiên những gì được thêm vào. Để tránh vấn đề này bạn cần một nền tảng đã được thiết kế với các ứng dụng có sẵn ngay từ đầu và sau đó có thể thêm dữ liệu lên đầu.
Ứng dụng web không thể bảo mật
Vào cuối những năm 1990, một cảnh tưởng kinh khủng đã xảy ra trong ngành công nghiệp phần mềm: các lỗi bảo mật trong các chương trình C / C ++ không phải là những lỗi hiếm gặp mà có thể giải quyết bằng các quy trình đặc biệt. Chúng xuất hiện khắp nơi. Mọi người bắt đầu nhận ra rằng nếu một phần của C / C + + được tiếp xúc với internet, sẽ có nhiều cách để khai thác lỗ hổng.
Chúng ta có thể thấy được sự bất lực của thế giới khi đọc báo cáo của SANS về Code Red từ năm 2001:
“ĐẠI DIỆN CỦA MICROSOFT VÀ CÁC CƠ QUAN AN NINH HOA KỲ ĐÃ TỔ CHỨC MỘT CUỘC HỌP BÁO HƯỚNG DẪN NGƯỜI DÙNG TẢI XUỐNG BẢN VÁ CÓ SẴN TỪ MICROSOFT VÀ CHO BIẾT NÓ LÀ “MỘT NGHĨA VỤ CÔNG DÂN” PHẢI TẢI BẢN VÁ NÀY. CNN VÀ CÁC KÊNH TIN TỨC KHÁC ĐƯA TIN NGAY SAU SỰ LÂY LAN CỦA CODE RED, KÊU GỌI NGƯỜI DÙNG CÀI ĐẶT BẢN VÁ”
Windows đã có cập nhật tự động, nhưng nếu tôi nhớ chính xác chúng đã không được bật một cách mặc định. Ý tưởng về một phần mềm có thể thay đổi mà không có sự cho phép của người dùng là điều cấm kỵ.
Dấu hiệu đầu tiên của máy khi nhiễm Blaster
Ngành công nghiệp này bắt đầu thay đổi, nhưng có rất nhiều lời than phiền và phản đối. Trong khi những người dùng Linux và Mac cho rằng đây là một vấn đề dành riêng cho Microsoft … rằng hệ thống của họ được xây dựng bởi một đội ngũ lập trình cao cấp hơn. Vì vậy, trong khi Microsoft chấp nhận rằng họ phải đối mặt với một cuộc khủng hoảng đang tồn tại và giới thiệu “secure development lifecycle” (vòng đời phát triển an toàn) (một chương trình đào tạo lớn và đúng quá trình) các đối thủ cạnh tranh của họ đã rất ít thực hiện. Redmond thêm một bức tường lửa vào Windows XP và đưa ra các code bảo mật. Code mobile bị hạn chế. Vì nó rõ ràng là nguồn gốc các lỗi bảo mật đến từ “Patch Tuesday” được giới thiệu. Các hacker thông minh tiếp tục phát hiện ra rằng các loại lỗi đã từng được coi là “lành tính” và khai thác các lỗi nhỏ khác đến khi có thể thực hiện một việc gì đó. Cộng đồng Mac và Linux dần dần thức tỉnh vì một thực tế rằng, chúng không thể miễn dịch với virus và các cách khai thác mới lạ.
Bước ngoặt cuối cùng xảy ra vào năm 2008 khi Google ra mắt Chrome, một dự án đáng chú ý vì thực tế họ đã đặt nỗ lực rất lớn vào một sandbox phức tạp. Nói cách khác, các kỹ sư tốt nhất của ngành công nghệ đã chính thức thừa nhận họ không bao giờ có thể tạo phần mềm C++ an toàn cho dù họ cố gắng như thế nào.
Bây giờ đến lượt của web
Thật không may, web đã không thể đưa chúng tôi đến “vùng đất hứa” nơi các ứng dụng đều đáng tin cậy. Trong khi ứng dụng web là loại sandbox từ hệ điều hành máy chủ, và đó là điều tốt, các ứng dụng đã mạnh mẽ hơn so với khoảng năm 2001. Thay vì mãi bám theo các vấn đề ban đầu, để cho web trở nên tốt hơn chỉ cần thay thế buffer overflow (lỗi tràn bộ đệm) với cái khác. Các ứng dụng trên desktop đã khai thác các danh mục như “double free”, “stack smash”, “use after free” …, các ứng dụng web sửa chữa những lỗi đó nhưng sau đó tự vấp lại những sai lầm tương tự: SQL injection, XSS, XSRF, header injection, nhầm lẫn MIME, …
Điều này dẫn đến một luận điểm rất đơn giản:
Tôi cho rằng bạn không thể viết các ứng dụng web an toàn.
Chúng ta hãy cùng nhau vượt qua vấn đề bảo mật. Tôi không nói về tất cả các ứng dụng web. Có bạn hoàn toàn có thể tạo một HTML Hello World an toàn.
Tôi đang muốn nói về các ứng dụng web thực tế có quy mô lớn hơn, được viết trong các điều kiện thực tế. Đó là niềm tin của tôi suốt 8 năm qua tại Google, nơi mà tôi quan sát các nhà phát triển web giỏi và sáng tạo nhất khai thác phần mềm nhiều lần.
Nhóm bảo mật của Google là một trong những người giỏi nhất thế giới, có lẽ là giỏi nhất luôn và họ đã đưa ra hướng dẫn hữu ích này cho một số sai lầm hàng đầu mà mọi người trong chương trình đào tạo nội bộ của họ mắc phải. Đây là lời khuyên của họ về việc gửi dữ liệu một cách an toàn cho trình duyệt để hiển thị:
Để khắc phục, bạn có thể thực hiện một số thay đổi. Bất kỳ thay đổi nào trong này sẽ ngăn chặn các cuộc tấn công hiện tại có thể xảy ra, nhưng nếu bạn thêm một số lớp bảo vệ (“defense in depth”) bạn sẽ chống lại khả năng bạn nhận được một trong những báo lỗi sai và chống lại lỗ hổng trình duyệt trong tương lai. Trước tiên, sử dụng XSRF như đã thảo luận trước đó để đảm bảo rằng các kết quả JSON có chứa dữ liệu bí mật chỉ được trả về các trang của riêng bạn. Thứ hai, các trang phản hồi JSON của bạn chỉ nên hỗ trợ những request POST, ngăn không cho script được tải qua một script tag. Thứ ba, bạn nên chắc chắn rằng script không không được thực thi. Cách chuẩn mực để làm điều này là nối một số tiền tố không thực thi vào nó, như ])}while(1);</x>. Một script chạy trong cùng một tên miền có thể đọc nội dung của response và loại bỏ prefix, nhưng các script chạy trong các miền khác thì không thể.
LƯU Ý: Làm cho script không thực thi nên tinh tế hơn. Có thể điều đó làm cho một script thực thi có thể thay đổi trong tương lai nếu các tính năng hoặc ngôn ngữ mới được giới thiệu. Một số người sẽ đề nghị bạn, có thể bảo vệ script bằng cách làm cho nó một comment với/* và */, nhưng điều đó không hề đơn giản.
Đọc những thứ nhảm nhí về những “phép màu” và truyền thuyết luôn khiến tôi buồn cười. Chúng nên chỉ là một trò đùa, nhưng đó lại thực sự là những thứ cơ bản mà mọi nhà phát triển web của Google đều mong đợi, chỉ để đưa một số dữ liệu lên màn hình.
Trên thực tế bạn có thể làm tất cả những điều đó và nó vẫn không hoạt động. Cuộc tấn công từ bọn “trộm” vẫn có thể đánh cắp dữ liệu từ một ứng dụng web ngay cả khi đã thực hiện những biện pháp phòng chống trên và không có bất kỳ lỗ hổng nào. Cái chúng cần là khai thác lỗ hổng thiết kế không thể thay đổi trong nền tảng web. Game over.
Tệ hơn nữa! Việc bảo vệ các endpoint REST / JSON chỉ là một trong những vấn đề bảo mật khác mà một nhà phát triển web hiện đại cần phải hiểu. Ngoài ra còn hàng tá điều khác (đây là một ví dụ thú vị và một cái khác thú vị không kém).
Vấn đề cốt lõi
Hầu như tất cả các vấn đề bảo mật trên web đều đến từ một vài vấn đề thiết kế cơ bản:
Bộ đệm không xác định được độ dài của chúng
Các giao thức được thiết kế cho document không phải ứng dụng
Same Origin Policy (SOP)
Theo dõi kích thước của bộ đệm của bạn vì đó là một vấn đề cổ điển trong các chương trình C và web có cùng một vấn đề: các khai thác nhắm vào XSS và SQL injection đều dựa trên việc tạo sự nhầm lẫn về nơi bộ đệm code bắt đầu và bộ đệm dữ liệu kết thúc. Web hoàn toàn phụ thuộc vào các giao thức và định dạng format, do đó các bộ đệm luôn được phân tích cú pháp để tìm ra độ dài của chúng. Điều này mở ra con đường thất thoát dữ liệu, việc thay thế và các vấn đề khác không cần phải tồn tại.
Cách fix: Tất cả bộ đệm phải được thêm độ dài vào từ cơ sở dữ liệu đến frontend server, đến UI. Không nên scan bất cứ điều gì, vì điều đó tạo cơ hội cho “đạo chích” xác định nơi dữ liệu kết thúc. Lưu ý rằng điều này đòi hỏi các giao thức đều ở dạng nhị phân, định dạng và logic UI của toàn bộ.
HTTP và HTML đều được thiết kế cho document. Khi Egor Homakov có thể phá vỡ sản phẩm bảo mật “xác thực 2 yếu tố” của Authy bằng cách gõ “../sms” bên trong trường nhập mã SMS, ông đã thành công vì giống như tất cả các dịch vụ Web, được Authy xây dựng trên một thiết kế cho hypertext chứ không phải phần mềm. Path Traversal sẽ hữu ích nếu những gì bạn đang truy cập là actual của các thư mục với các tập tin HTML trong chúng, như Sir Tim định thực hiện. Nếu bạn đang trình bày một API như là “document” thì path traversal có thể gây nguy hiểm.
Còn vấn đề REST không đủ tốt khi trả về XML, tuy nhiên ngày nay XML đã trở nên lạc hậu và thay vào là các trang web sử dụng JSON, một định dạng được thiết kế khá tệ về vấn đề bảo mật.
Cách fix: Chúng ta hãy ngừng ảo tưởng cho rằng REST là một giải pháp hay. Vì đó là một ý tưởng tồi tệ, nó làm cho HTTP chuyển hướng đến một nơi nào đó và không phải chỉ để thực hiện cho trình duyệt. Điều này chỉ dẫn đến một kết thúc đau đớn. Vậy nên các giao tiếp giữa client/server nên sử dụng các giao thức nhị phân được thiết kế đặc biệt cho trường hợp sử dụng RPC.
Same Origin Policy (SOP) là một kinh nghiệm phát triển khác được đúc kết ngay trong cuốn tiểu thuyết của Stephen King:
Hành vi kiểm tra cùng nguồn gốc và các cơ chế liên quan không được xác định rõ trong một số trường hợp ngoài dự đoán … điều này gây ra số lượng đáng kể các vấn đề về bảo mật.
Ngoài ra, nhiều hoạt động của legacy cross-domain có trước JavaScript không phải là đối tượng kiểm tra cùng nguồn gốc.
Cuối cùng, các loại tấn công nhất định, chẳng hạn như thu hồi DNS hoặc các máy chủ proxy từ phía máy chủ, cho phép kiểm tra tên máy chủ lưu trữ bị phá vỡ một phần.
SOP là kết quả của Netscape lên một định dạng tài liệu. Nó không thực sự có tác động ý nghĩa và bạn sẽ không thiết kế một nền tảng ứng dụng dựa trên cách đó nếu bạn đã có hơn 10 ngày để thực hiện. Đối với một hackathon trong vòng 10 ngày chuyện đó có thể diễn ra tồi tệ hơn.
Dù chúng tôi rất thông cảm, tuy nhiên SOP luôn là trung tâm của cuộc tấn công bởi bọn HEIST và chúng dường như phá huỷ hầu hết các ứng dụng web thực tế bằng những cách mà không thể khắc phục được. Đó cũng là một lý do nữa khiến việc viết các ứng dụng web an toàn là điều không thể.
Cách fix: Một ứng dụng cần có thông tin nhận dạng rõ ràng và không được chia sẻ các token bảo mật với nhau mặc định. Nếu bạn không có quyền truy cập vào server, bạn không thể gửi tin nhắn.
Ngoài ra còn một loạt các vấn đề về thiết kế khác trên web khiến cho việc bảo mật trở nên khó khăn, nhưng những ví dụ trên có lẽ cũng đủ để mô tả được sự khó khăn đó.
Kết
HTML 5 như là một dịch bệnh trong ngành của chúng ta. Mặc dù có một số điều khá tốt nhưng những điểm tốt này thì các nền tảng ứng dụng khác cũng có, tuy nhiên hầu như không có bất kỳ sai sót về thiết kế cốt lõi của web. Đây là lý do tại sao web biến mất trên điện thoại di động: khi trình bày cùng với các nền tảng cạnh tranh đã được thiết kế thực sự, các lập trình viên gần như đã chọn native. Chúng tôi không thiếu bất cứ điều gì ngoài điện thoại di động. Chúng tôi rất cần một cách phân phối thuận tiện các ứng dụng được bảo mật, an toàn, tự động cập nhật lên desktop và laptop.
Ngày trước, web đã bị khóa trong một cuộc cạnh tranh với các nền tảng độc quyền khác như Flash, Shockwave và Java. Các trang web đã được mở lại nhưng chúng tồn tại như một nền tảng cạnh tranh không rõ ràng. Tuy nhiên nhiều lập trình viên vẫn phát triển với lòng trung thành của họ.