Trong loại bài viết về bảo mật khi lập trình website bằng PHP của tác giả Dave Child, ở phần 1 và phần 2 chúng ta đã điểm qua những lỗi căn bản khi tiến hành lập trình dự án website và làm cách nào khắc phục được những lỗi này. Tin chắc rằng qua 2 phần này nhiều webmaster cũng đã nhìn thấy rất nhiều sai sót bị mình bỏ qua đúng không. Trong bài viết này chúng ta sẽ tìm hiểu một khía cạnh sâu hơn trong vấn đề bảo mật và cách khắc phục chúng.
Nội dung được dịch từ bài viết Writing Secure PHP, Part 3 bởi babyinternet.
Ghi rõ nguồn http://vnwebmaster.com khi phát hành tại website khác
Phụ mục
Bối cảnh và hiện thực website
Trước khi chúng ta đến với những phần nội dung quan trọng hơn tôi muốn giành ít phút để nói về bối cảnh. Nếu bạn đang chạy một website nhó (blog chẳng hạn) và thường xuyên backup dữ liệu để đảm bảo an toàn cho hệ thống thì có nhiều khả năng đây không phải là một giải pháp tốt (có vẻ ngược đời nhỉ :p ). Nếu như kẻ tấn công (hacker) không gây hại gì nhiều đối với bạn (và thông thường chỉ là các trò hacked by… vớ vẩn) và bạn chỉ mất chưa đến 10 phút để restore dữ liệu thì quan tâm quá nhiều đến an ninh của website có vẻ sẽ là một sự lãng phí thời gian và tiền của quá lớn so với thực tế. Ở một chiến tuyến khác, nếu bạn điều hành một website với hàng chục (thậm chí hàng trăm, hàng ngàn) giao dịch trực tuyến, các thông tin thẻ tín dụng được lưu trữ trên website bạn thì mối quan tâm về an ninh cao là chính đáng và rất đáng đầu tư.
Nói như vậy không có nghĩa là bạn bỏ mặc website của bạn khi nó là site be bé xinh xinh đâu đấy nhé :wink: Chỉ có điều chúng ta không nên quá đặt nặng nó mà thôi.
Độ dài cơ sở dữ liệu
Một cơ sở dữ liệu (ở đây chúng ta đang nói đến MySQL nhưng có thể áp dụng cho các cơ sở dữ liệu khác) có một độ dài nhất định đối với các trường dữ liệu. Trong MySQL chúng ta có thể dễ dàng tìm thấy độ dài giới hạn của từng loại dữ liệu (cái này các bạn xem thêm ở mục MySQL nhé).
Một lập trình viên thiếu kinh nghiệm có thể sẽ khôgn chú ý nhiều đến vấn đề này và thường chỉ phỏng đoán giá trị tương ứng mà họ cần. Lấy một ví dụ đơn giản: Một trường dữ liệu dạng blob có khả năng chứa tối đa 65.535 ký tự. Việc này có thể chẳng là vấn đề gì bởi một bài viết có độ dài thường nhỏ hơn số lượng ký tự này. Vấn đề ở chỗ nếu bài viết có độ dài là 100,000 ký tự thì sao :ohmy: . Trong trường hợp kĩ năng lập trình tốt, bạn đã thiết lập tắt các báo lỗi, lúc đó dữ liệu không thể được đưa vào cơ sở dữ liệu (vì không phù hợp) và sẽ bị biến mất.
Hãy nhớ rằng những kẻ tấn công luôn tìm mọi cách để website của bạn hiển thị những thông báo lỗi. Nếu website bạn hiển thị thông báo lỗi, kẻ tấn công sẽ dựa vào đó để khai thác tiếp các thông tin. Và ở ví dụ trên, đừng nói chi 100.000 ký tự, cho dù nhiều hơn hacker cũng có thể dễ dàng thực hiện được để tìm kiếm thông tin mà hắn ta cần.
Để khắc phục lỗi này rất đơn giản. Chúng ta chỉ cần kiểm tra tính hợp lệ của dữ liệu trước khi thêm nó vào cơ sở dữ liệu của mình. Bạn chỉ cần đếm độ dài của văn bản đưa vào xem có phù hợp với khả năng chứa đựng của dữ liệu hay không và loại bỏ hoặc hiển thị thông báo để người dùng biết và tránh xa những bài viết quá dài.
Mật khẩu quá yếu
Từ điển là công cụ hữu ích cho hacker (trong bài viết trước chúng ta đã nói về vấn đề dictionary attack rồi). Nếu bạn có một website đã bị chiếm quyền, kẻ tấn công có thể dễ dàng có được thông tin đăng nhập cơ sở dữ liệu và có được danh sách các user và password đã được mã hóa. Hắn không thể dịch ngược mật khẩu đã được mã hóa (md5 chẳng hạn) về thành mật khẩu thông thường để truy cập.
Mật khẩu yếu là nguyên nhân chính dẫn đến việc bị chiếm quyền
Tuy nhiên, như đã nói ở trên, hầu hết các hacker đều có một danh sách các từ phổ biến và dữ liệu mã hóa của những từ này để so sánh. Hoặc hắn có thể dễ dàng tìm kiếm từ Google thông qua mật khẩu đã mã hóa. Việc này thực hiện khá dễ dàng, nên nếu hắn có một mật khẩu đã được mã hóa, hắn có thể mò được mật khẩu chưa mã hóa.
Cách để ngăn ngừa việc này là chúng ta nên sử dụng một mật khẩu đủ mạnh. Sức mạnh của mật khẩu nằm ở độ phức tạp của nó. Qui luật số một là nên tránh những mật khẩu đơn giản như “12345”, “sex”, “qwerty” hay những thứ tương tự (vì chúng quá đơn giản và là những mật khẩu được thử đầu tiên). Một mật khẩu được tạo từ 1 từ cũng là một mật khẩu yếu kém :rolleyes: Một mật khẩu đủ mạnh là mật khẩu kết hợp giữa số và chữ, giữa chữ hóa và chữ thường kết hợp với các ký tự đặt biệt. Nhưng cũng đừng đặt mật khẩu là “password12345” nhé :D
Khách hàng của bạn
Khách hàng là rủi ro lớn nhất về bảo mật. Bạn có tin hay không :D
Một số công ty thuê một nhà phát triển web giá rẻ nào đó thực hiện một vài chỉnh sửa nhỏ trên website sau vài tháng (mà họ phải đổ hàng đống tiền để xây dựng). Những công ty này dễ dàng cung cấp tài khoản FTP chi tiết cho những người kia khi được yêu cầu (mặc dù họ chẳng biết có cần hay không). Tôi đã thử truy cập vào một website của một công ty ở địa phương và xem các thông tin về công ty thiết kế website của website này. Tôi gọi cho công ty này và nói rằng tôi là nhân viên của công ty thiết kế website, yêu cầu họ gửi tài khoản FTP để tôi thực hiện việc nâng cấp. Họ đã gửi cho tôi mà không có bất kì thắc mắc nào :bomb:
Thật không may là chẳng có cách nào để đề phòng trường hợp bảo mật này. Cách tốt nhất là khách hàng phải ý thức được thông tin của họ cần được chính họ bảo mật mà thôi :(
Code Injection (Cross-Site Scripting)
Không giống như SQL Injection dựa vào việc sử dụng các kí tự đặc biệt để kiểm soát câu truy vấn, Cross-Site Scripting dựa vào các lỗi trong quá trình xuất dữ liệu. Nói một cách đơn giản hơn, Code Injection dựa vào các lỗi trong quá trình output dữ liệu để chèn các đoạn mã HTML có hại lên website của bạn khi nó hiển thị cho người dùng.
Lấy một ví dụ đơn giản, trong một form đăng ký thành viên. Người dùng sẽ đang ký một username và một mật khẩu cùng những thông tin có liên quan để trở thành thành viên. Nếu bạn không kiểm soát độ dài của một username, kẻ tấn công có thể điền vào phần thông tin username như sau:
UsernameABC
Bất kì ai khi xem website có chứa username của người dùng này chỉ thấy được UsernameABC, nhưng đoạn javascript có hại được chèn vào sẽ âm thầm chạy cùng lúc và thực hiện những thao tác có hại cho người dùng.
Có nhiều việc để gây hại cho bạn như chèn một đoạn mã khiêu dâm, lấy cookie hay thêm vào đó một phần mềm keylogger…
Có nhiều cách để khắc phục việc này. Trước tiên bạn có thể mã hóa HTML cho thông tin này. Hoặc bạn có thể loại các đoạn mã HTML trước khi lưu, giới hạn các kí tự đặc biệt trong tên người dùng…
Một cách khác, bạn có thể giới hạn ký tự cho tên người dùng. Một số website chỉ cho phép người dùng nhập thông tin dạng chữ và số, các kí tự đặt biệt và các tag HTML không được cho phép để đăng ký…
Rõ ràng, ở đây chúng ta chỉ xét trong trường hợp trường dữ liệu Username, các trường hợp khác (như nội dung bài viết) chúng ta đã bỏ qua. Tuy nhiên, điều đó không có nghĩa là nó không xảy ra đối với các trường dữ liệu khác. Tùy theo từng trường hợp chúng ta có một cách xử lý thích hợp.
Khắc phục hậu quả
Một phần không thể bỏ qua của một chiến lược an ninh mạng là giả lập các tình huống có thể xảy ra nhằm tìm biện pháp xử lý thích hợp trước khi điều đó thực sự xảy ra. Bạn phải đảm bảo rằng chúng ta tránh được những thiệt hại nặng nề và khắc phục hậu quả nhanh nhất có thể.
Đối phó với khách hàng trong trường hợp này không phải là dễ. Bạn sẽ nhận được một cơn giận dữ lớn cùng những lời ca thán doanh số giảm sút, uy tín ảnh hưởng …. Nói chung họ sẽ cho bạn nhiều cảm xúc bất ngờ lắm đấy :D . Nhiều nhà phát triển web hoang mang và lo lắng khi xảy ra lỗi bảo mật. Nếu bạn có một kế hoạch đề phòng rủi ro tốt bạn sẽ tự tin hơn khi giao tiếp với họ và khiến tinh thần họ tốt hơn, yên tâm hơn vì mọi việc vẫn nằm trong tầm kiểm soát của bạn.
Trước tiên hãy giành thời gian tìm hiểu xem chuyện gì đang diễn ra: là một cuộc tấn công DDOS khiến cho website của bạn không thể truy cập được hay là do một ai đó ở data center gấp phải sợ dây dẫn điện khiến cho Server của bạn bị shutdown :D ? Là cơ sở dữ liệu bị sửa, bị xóa? Một cuộc tấn công từ chối dịch vụ hay là server của bạn không chịu nổi khi lượng truy cập quá nhiều ? Bạn cần phải tìm hiểu kĩ nguyên nhân để biết đựoc mình đang đối phó với chuyện gì. Một diễn đàn chưa chắc không thể truy cập được do bị tấn công mà còn có nhiều nguyên nhân khác nữa.
Giả sử đây là vấn đề an ninh, hãy bình tĩnh và trấn an khách hàng. Nếu cơ sở dữ liệu bị an đó xâm nhập: không hề gì, tất cả đã được mã hóa. Nếu ai đó upload backdoor hoặc 1 file gây hại nào đó lên server: chuyện nhỏ, bạn chỉ cần xóa tất cả các file và upload 1 phiên bản đã backup lên lại.
Bạn đã có thời gian để tìm hiểu nguyên nhận và các lỗ hổng có thể bị tấn công. Hãy thử kiểm tra lại log đăng nhập và các lỗi ở trang đăng nhập trước. Ngoài ra, các hacker thường là thành viên của một trang web về hacking nào đó. Bạn cũng nên liệt kê lại các trang web về hacking mà website của bạn được nói đến cũng như xem thử họ đang nói gì về website của bạn. Bằng cách này bạn sẽ phát hiện ra rất nhiều điều bổ ích. Bạn cũng nên để ý những điểm nho nhỏ giữa các website bị hack trước đó để tìm kiếm thông tin (ví dụ các website bị hack đều chạy cùng một phiên bản Apache hoặc IIS, đều sử dụng mã nguồn phpBB – như http://vnwebmaster.com :D hay WordPress nhuw http://nhanweb.com ). Hãy thử so sánh với website bạn, biết đâu bạn tìm được nguyên nhân từ đó.
Một điều rất quan trọng là bạn nên sửa bất kì một lỗi có thể phát hiện ra nào trước khi tiến hành cho website hoạt động trở lại. Nên khôn ngoan để một thông báo “Bảo dưỡng website định kì” trước khi bạn khắc phục tất cả. Nếu không bạn đang tự lãng phí thời gian của bạn.
Share hosting
Share hosting có giá phải chăng hơn nên là lựa chọn hợp lý cho nhiều website và là nơi nhiều website được lưu trữ trên cùng một máy chủ. Hầu hết các website đêu được lưu trữ theo cách này và điều này cũng mang lại những yếu tố bảo mật khác hơn so với việc sử dụng server riêng.
Trước hết, sự an toàn của webiste bạn lúc này không nằm trong tay bạn mà nó nằm trong tay của công ty cung cấp dịch vụ hosting cho bạn. Họ có thể là người tốt, là kẻ gian tùy vào cách làm việc của họ. Hãy lắng nghe ý kiến của những webmaster khác trước khi quyết định sử dụng dịch vụ của một công ty nào đó bởi họ có thể xâm nhập vào cơ sở dữ liệu và lấy đi bất cứ thứ gì họ muốn trên website bạn bất cứ lúc nào.
Bạn hãy kiểm tra các thông tin về bảo mật mà họ đưa ra trước khi lựa chọn. Bảo mật trên share hosting chủ yếu dựa vào những thiết lập an toàn trên PHP kết hợp với việc disable những hàm quan trọng (hoặc có khả năng lợi dụng). Tuy nhiên, nhiều công ty không làm vậy :D
Các lỗ hổng liên quan đến share hosting phần lớn bạn ít có điều kiện để khắc phục cũng như hạn chế. Một thiết lập máy chủ yếu sẽ cho phép đọc được dễ dàng các tập tin như /etc/passwd và httpd.conf. Những máy chủ như vậy thường đem lại cho các user trên cùng máy chủ cơ hội xâm nhậm các website khác. Lưu trữ dữ liệu được khuyến khích vì nó an toàn hơn nhưng nếu tập tin lưu thông tin truy cập cơ sở dữ liệu của bạn bị đọc được thì việc truy cập vào cơ sở dữ liệu lại trở nên dễ dàng. Các tốt nhất trong trường hợp này là bạn thiết lập các thông tin đăng nhập cơ sở dữ liệu thông qua httpd.conf, sử dụng các biến môi trường (bạn cần liên lạc với bên cung cấp share hosting để làm việc này).
Tất nhiên, nếu đã sử dụng share hosting thì không thể nhận được sử an toàn 100%. Những thông tin mà tôi cung cấp trên đây chỉ giúp bạn hạn chế phần nào những cuộc tấn công từ chính máy chủ của bạn mà thôi. An toàn hơn, bạn nên sử dụng một máy chủ riêng bởi bạn có thể dễ dàng điều chỉnh và sủa đổi, sử dụng riêng… Vấn đề đối với máy chủ dùng riêng chính là chi phí.
Nội dung được dịch từ bài viết Writing Secure PHP, Part 3 bởi babyinternet.
Ghi rõ nguồn http://vnwebmaster.com khi phát hành tại website khác