Followers

Search

Nhập từ khóa tìm kiếm của bạn và nhấn enter

Liên Hệ

Name

Email *

Message *

9 mẹo bảo mật để bảo vệ trang web của bạn khỏi hacker

Xin chào !
Hôm nay blog xin chia sẻ một số mẹo để tối ưu hóa bảo mật trang web của bạn và tránh các sự cố về hacker.




Bạn không thể nghĩ rằng trang web của bạn không có bất cứ thứ gì có giá trị nào để bị tấn công, nhưng các trang web bị xâm nhập mọi lúc. Phần lớn các vi phạm bảo mật trang web không phải là để ăn cắp dữ liệu của bạn hoặc làm hỏng trang web của bạn mà thay vào đó cố gắng sử dụng máy chủ của bạn như là một email để gửi thư rác, hoặc để thiết lập một máy chủ web tạm thời, thường để phục vụ các tệp tin có tính chất bất hợp pháp. Các cách phổ biến khác để lạm dụng máy bị xâm nhập bao gồm việc sử dụng các máy chủ của bạn như là một phần của một mạng botnet, hoặc để khai thác cho Bitcoins. Bạn thậm chí có thể bị đánh trúng bởi ransomware. 


Hacking được thực hiện thường xuyên bằng các tập lệnh tự động được viết để quét Internet nhằm cố gắng khai thác các vấn đề bảo mật trang web đã biết trong phần mềm. Đây là 10 mẹo hàng đầu của chúng tôi để giúp bạn và trang web của bạn an toàn trên mạng.

1. Cập nhật phần mềm

Có vẻ đây là một điều đương nhiên ai cũng sẻ làm, nhưng đảm bảo rằng bạn giữ tất cả phần mềm được cập nhật là điều quan trọng trong việc giữ cho trang web của bạn an toàn. Điều này áp dụng cho cả hệ điều hành máy chủ và bất kỳ phần mềm nào bạn đang chạy trên trang web của bạn như là một CMS hoặc diễn đàn. Khi lỗ hổng bảo mật trang web được tìm thấy trong phần mềm, tin tặc nhanh chóng cố gắng lạm dụng chúng.

Nếu bạn đang sử dụng một giải pháp quản lý lưu trữ thì bạn không cần phải lo lắng nhiều về việc áp dụng các bản cập nhật bảo mật cho hệ điều hành vì công ty lưu trữ họ sẻ thay bạn làm những việc này.

Nếu bạn đang sử dụng phần mềm của bên thứ ba trên trang web của bạn chẳng hạn như một CMS hoặc diễn đàn, bạn nên đảm bảo rằng bạn đang nhanh chóng áp dụng bất kỳ miếng vá bảo mật. Hầu hết các nhà cung cấp đều có một danh sách gửi thư hoặc nguồn cấp dữ liệu RSS nêu rõ bất kỳ vấn đề về bảo mật trang web nào. WordPress, Umbraco và nhiều CMS khác sẽ thông báo cho bạn về những cập nhật hệ thống hiện có khi bạn đăng nhập.

Nhiều nhà phát triển sử dụng các công cụ như Composer, NPM, hoặc RubyGems để quản lý các phần mềm phụ thuộc của họ, và các lỗ hổng bảo mật xuất hiện trong một gói phần mềm bạn phụ thuộc nhưng không chú ý đến là một trong những cách dễ dàng nhất để bắt kịp. Đảm bảo bạn luôn cập nhật các tính năng phụ thuộc và sử dụng các công cụ như Gemnasium để nhận thông báo tự động khi một lỗ hổng được công bố ở một trong các thành phần của bạn.

2. SQL injection

Các cuộc tấn công SQL injection là khi kẻ tấn công sử dụng trường mẫu web hoặc tham số URL để truy cập hoặc thao tác cơ sở dữ liệu của bạn. Khi bạn sử dụng Transact SQL chuẩn, bạn dễ dàng vô tình chèn mã rogue vào truy vấn của bạn để có thể sử dụng để thay đổi các bảng, lấy thông tin và xóa dữ liệu. Bạn có thể dễ dàng ngăn chặn điều này bằng cách sử dụng các truy vấn parameterised, hầu hết các ngôn ngữ web có tính năng này và nó rất dễ thực hiện.


Xem xét truy vấn này:

"SELECT * FROM table WHERE column = '" + parameter + "';"

Nếu một kẻ tấn công thay đổi tham số URL để vượt qua trong 'hoặc' 1 '=' 1 điều này sẽ làm cho các truy vấn như thế này:

"SELECT * FROM table WHERE column = '' OR '1'='1';"

Kể từ '1' bằng '1', điều này sẽ cho phép kẻ tấn công thêm một truy vấn bổ sung vào cuối câu lệnh SQL cũng sẽ được thực hiện.


Bạn có thể sửa câu hỏi này bằng cách tham số nó một cách rõ ràng. Ví dụ, nếu bạn đang sử dụng MySQLi trong PHP, điều này sẽ trở thành:
$stmt = $pdo->prepare('SELECT * FROM table WHERE column = :value');
$stmt->execute(array('value' => $parameter));

3. XSS

Các cuộc tấn công cross-site scripting (XSS) tấn công JavaScript độc hại vào các trang của bạn, sau đó chạy trong trình duyệt của người dùng và có thể thay đổi nội dung trang hoặc ăn cắp thông tin để gửi lại cho kẻ tấn công. Ví dụ: nếu bạn hiển thị nhận xét trên một trang không có xác nhận hợp lệ thì kẻ tấn công có thể gửi nhận xét chứa các thẻ tập lệnh và JavaScript, có thể chạy trong trình duyệt của mọi người dùng khác và ăn cắp cookie đăng nhập của họ, cho phép cuộc tấn công kiểm soát tài khoản của mọi người dùng đã xem bình luận. Bạn cần đảm bảo rằng người dùng không thể đưa nội dung JavaScript đang hoạt động vào các trang của bạn.

Đây là mối quan tâm đặc biệt trong các ứng dụng web hiện đại, nơi các trang được xây dựng chủ yếu từ nội dung người dùng và trong nhiều trường hợp tạo ra HTML, sau đó cũng được giải thích bởi các khuôn khổ front-end như Angular và Ember. Các khuôn khổ này cung cấp nhiều sự bảo vệ XSS, nhưng pha trộn máy chủ và kết xuất của khách hàng tạo ra các đường tấn công mới và phức tạp hơn: không chỉ là chích JavaScript vào HTML hiệu quả, mà bạn còn có thể chèn nội dung sẽ chạy mã bằng cách chèn các chỉ thị Angular hoặc sử dụng Ember người giúp đỡ.

Chìa khóa ở đây là tập trung vào cách nội dung do người dùng tạo ra có thể thoát khỏi giới hạn mà bạn mong đợi và được trình duyệt hiểu như là một thứ khác mà bạn dự định. Điều này cũng tương tự như bảo vệ chống lại SQL injection. Khi tự động tạo ra HTML, sử dụng các hàm rõ ràng thực hiện các thay đổi bạn đang tìm kiếm (ví dụ: sử dụng element.setAttribute và element.textContent, sẽ tự động thoát bằng trình duyệt, chứ không phải tự thiết lập element.innerHTML bằng tay) hoặc sử dụng các hàm trong công cụ tạo khuôn mẫu của bạn sẽ tự động chạy thoát phù hợp hơn là kết nối chuỗi hoặc đặt nội dung HTML thô.


Một công cụ mạnh mẽ khác trong hộp công cụ của XSS Defender là Content Security Policy (CSP). CSP là một tiêu đề mà máy chủ của bạn có thể trả về cho trình duyệt để giới hạn cách thức và JavaScript được thực hiện như thế nào trong trang, ví dụ như không cho phép chạy bất kỳ tập lệnh nào không được lưu trữ trên miền của bạn, không cho phép nội tuyến JavaScript hoặc vô hiệu hóa eval (). Mozilla có một hướng dẫn tuyệt vời với một số cấu hình ví dụ. Điều này làm cho các tập lệnh của kẻ tấn công khó làm việc hơn, ngay cả khi chúng có thể đưa chúng vào trang của bạn.

4. Các thông báo lỗi

Hãy cẩn thận với bao nhiêu thông tin bạn đưa ra trong các thông báo lỗi của bạn. Chỉ cung cấp lỗi nhỏ cho người dùng của bạn, để đảm bảo rằng họ không rò rỉ bí mật hiện có trên máy chủ của bạn (ví dụ như các phím API hoặc mật khẩu cơ sở dữ liệu). Không cung cấp đầy đủ các chi tiết ngoại lệ, hoặc vì những điều này có thể làm cho các cuộc tấn công phức tạp như SQL injection dễ dàng hơn. Giữ các lỗi chi tiết trong nhật ký máy chủ của bạn và chỉ cho người dùng biết thông tin họ cần.

5. Phê duyệt / xác nhận hợp lệ phía máy chủ

Xác nhận phải luôn luôn được thực hiện cả trên trình duyệt và phía máy chủ. Trình duyệt có thể bắt các lỗi đơn giản như các trường bắt buộc trống và khi bạn nhập văn bản vào trường số. Tuy nhiên, chúng có thể được bỏ qua và bạn phải đảm bảo kiểm tra các xác nhận này và xác nhận máy chủ sâu hơn vì không thực hiện được điều đó có thể dẫn đến mã độc hại hoặc mã kịch bản được chèn vào cơ sở dữ liệu hoặc có thể gây ra các kết quả không mong muốn trong trang web của bạn.

6. Mật khẩu

Mọi người đều biết họ nên sử dụng mật khẩu phức tạp, nhưng điều đó không có nghĩa là họ luôn làm. Điều rất quan trọng là sử dụng mật khẩu mạnh đến máy chủ và khu vực quản trị trang web của bạn, nhưng cũng rất quan trọng để nhấn mạnh vào thực tiễn mật khẩu tốt cho người dùng của bạn để bảo vệ tính bảo mật của tài khoản của họ.

Nhiều người dùng có thể không thích nó, việc thực thi các yêu cầu về mật khẩu chẳng hạn như tối thiểu là khoảng tám ký tự, bao gồm một chữ cái và chữ viết hoa sẽ giúp bảo vệ thông tin của họ trong thời gian dài.

Mật khẩu phải luôn luôn được lưu trữ dưới dạng các giá trị mã hoá, tốt hơn là sử dụng một thuật toán băm một chiều như SHA. Sử dụng phương pháp này có nghĩa là khi bạn xác thực người dùng, bạn chỉ cần so sánh các giá trị được mã hóa. Để bảo mật trang web thêm, bạn nên làm muối mật khẩu bằng cách sử dụng muối mới cho mỗi mật khẩu.

Trong trường hợp có ai đó xâm nhập và đánh cắp mật khẩu của bạn, việc sử dụng mật khẩu đã băm có thể giúp hạn chế thiệt hại, vì việc giải mã chúng không thể thực hiện được. Một người nào đó tốt nhất có thể làm là một cuộc tấn công bằng từ điển hoặc tấn công bạo lực, về cơ bản đoán mọi sự kết hợp cho đến khi nó tìm thấy một trận đấu. Khi sử dụng mật khẩu muối, quá trình nứt một số lượng lớn mật khẩu thậm chí còn chậm hơn vì mỗi lần đoán phải được băm riêng cho mỗi muối + mật khẩu được tính toán rất tốn kém.


Rất may, nhiều CMS cung cấp cho người dùng quản lý ra khỏi hộp với rất nhiều các tính năng bảo mật trang web được xây dựng trong, mặc dù một số cấu hình hoặc mô-đun thêm có thể được yêu cầu sử dụng mật khẩu muối (trước Drupal 7) hoặc để thiết lập mật khẩu tối thiểu sức mạnh. Nếu bạn đang sử dụng .NET, bạn nên sử dụng các nhà cung cấp thành viên vì chúng rất có thể cấu hình, cung cấp bảo mật trang web sẵn có và bao gồm các điều khiển readymade để đăng nhập và đặt lại mật khẩu.

7. Tải lên tệp tin

Cho phép người dùng tải tệp lên trang web của bạn có thể là nguy cơ bảo mật trang web lớn, ngay cả khi chỉ cần thay đổi avatar của họ. Rủi ro là bất kỳ tệp nào tải lên vô tội vạ mà có thể xem, có thể chứa một tập lệnh được thực hiện trên máy chủ của bạn hoàn toàn mở ra trang web của bạn.

Nếu bạn có một hình thức tải lên tập tin sau đó bạn cần phải điều trị tất cả các file với nghi ngờ tuyệt vời. Nếu bạn cho phép người dùng tải lên hình ảnh, bạn không thể dựa vào phần mở rộng tệp hoặc loại mime để xác minh rằng tệp là một hình ảnh vì chúng có thể dễ bị giả mạo. Ngay cả việc mở tập tin và đọc phần đầu, hoặc sử dụng các chức năng để kiểm tra kích thước hình ảnh không phải là bằng chứng đầy đủ. Hầu hết các định dạng hình ảnh cho phép lưu trữ một phần nhận xét có thể chứa mã PHP có thể được thực hiện bởi máy chủ.

Vậy bạn có thể làm gì để ngăn chặn điều này? Cuối cùng, bạn muốn ngăn người dùng không thể thực hiện bất kỳ tệp nào họ tải lên. Theo mặc định, các máy chủ web sẽ không cố gắng thực thi các tệp có phần mở rộng hình ảnh nhưng không nên chỉ dựa vào việc kiểm tra phần mở rộng tệp như là một tệp với tên image.jpg.php đã được biết đến qua.


Một số tùy chọn là đổi tên tệp khi tải lên để đảm bảo mở rộng tệp chính xác hoặc để thay đổi quyền truy cập tập tin, ví dụ chmod 0666 do đó không thể thực hiện được. Nếu sử dụng * nix bạn có thể tạo tệp tin .htaccess (xem bên dưới) sẽ chỉ cho phép truy cập vào tập tin thiết lập ngăn chặn cuộc tấn công mở rộng kép được đề cập trước đó.


deny from all
    <Files ~ "^\w+\.(gif|jpe?g|png)$">
    order deny,allow
    allow from all
    </Files>


Cuối cùng, giải pháp được đề xuất là để ngăn chặn truy cập trực tiếp vào các tập tin tải lên tất cả cùng nhau. Bằng cách này, bất kỳ tệp tin nào được tải lên trang web của bạn được lưu trữ trong một thư mục bên ngoài webroot hoặc trong cơ sở dữ liệu dưới dạng blob. Nếu tệp của bạn không thể truy cập trực tiếp, bạn sẽ cần tạo một tập lệnh để lấy các tập tin từ thư mục riêng (hoặc trình xử lý HTTP trong .NET) và đưa chúng tới trình duyệt. Thẻ ảnh hỗ trợ thuộc tính src không phải là URL trực tiếp tới hình ảnh, do đó, thuộc tính src của bạn có thể trỏ đến tập lệnh phân phối tập tin của bạn cung cấp cho bạn đặt đúng loại nội dung trong tiêu đề HTTP. Ví dụ:
<img src="/imageDelivery.php?id=1234" />
     
<?php
      // imageDelivery.php
     
      // Fetch image filename from database based on $_GET["id"]
      ...
     
      // Deliver image to browser
       Header('Content-Type: image/gif');
      readfile('images/'.$fileName);  
     
?>

Hầu hết các nhà cung cấp lưu trữ đều phải đối phó với cấu hình máy chủ cho bạn, nhưng nếu bạn đang lưu trữ trang web của bạn trên máy chủ của riêng bạn thì có rất ít điều bạn muốn kiểm tra.

Đảm bảo bạn có một thiết lập tường lửa, và đang chặn tất cả các cổng không cần thiết. Nếu có thể thiết lập một DMZ (Khu phi quân sự) chỉ cho phép truy cập vào cổng 80 và 443 từ thế giới bên ngoài. Mặc dù điều này có thể không khả thi nếu bạn không có quyền truy cập vào máy chủ của mình từ mạng nội bộ vì bạn cần mở cổng để cho phép tải tệp lên và đăng nhập từ xa vào máy chủ của bạn qua SSH hoặc RDP.

Nếu bạn cho phép các tệp tải lên từ Internet chỉ sử dụng các phương thức truyền tải an toàn đến máy chủ của bạn như SFTP hoặc SSH.

Nếu có thể, cơ sở dữ liệu của bạn đang chạy trên một máy chủ khác với máy chủ web của bạn. Làm điều này có nghĩa là máy chủ cơ sở dữ liệu không thể truy cập trực tiếp từ thế giới bên ngoài, chỉ có máy chủ web của bạn có thể truy cập vào nó, giảm thiểu nguy cơ dữ liệu của bạn bị lộ.


Cuối cùng, đừng quên giới hạn quyền truy cập vào máy chủ của bạn.

8. HTTPS

HTTPS là một giao thức được sử dụng để cung cấp bảo mật qua Internet. HTTPS đảm bảo với người dùng rằng họ đang nói chuyện với máy chủ họ mong đợi và không ai khác có thể đánh chặn hoặc thay đổi nội dung mà họ đang xem qua.

Nếu bạn có bất cứ thứ gì mà người dùng của bạn muốn riêng tư, bạn nên chỉ sử dụng HTTPS để phân phối nó. Điều đó tất nhiên có nghĩa là thẻ tín dụng và các trang đăng nhập (và các URL họ gửi đến) nhưng thường xa hơn các trang web của bạn quá. Một mẫu đăng nhập thường sẽ thiết lập một cookie ví dụ, được gửi cùng với mọi yêu cầu khác đến trang của bạn mà người dùng đăng nhập làm và được sử dụng để xác thực các yêu cầu đó. Một kẻ tấn công trộm cắp này sẽ có thể bắt chước người dùng một cách hoàn hảo và tiếp quản phiên đăng nhập của họ. Để đánh bại các loại tấn công này, bạn hầu như luôn muốn sử dụng HTTPS cho toàn bộ trang web của mình.

Điều đó không còn khó khăn và tốn kém như trước nữa. Hãy mã hóa cung cấp các chứng chỉ hoàn toàn miễn phí và tự động, bạn cần phải bật HTTPS, và có các công cụ cộng đồng hiện có sẵn cho một loạt các nền tảng và khuôn khổ chung để tự động thiết lập điều này cho bạn.

Đáng chú ý là Google đã thông báo rằng họ sẽ tăng bạn trong bảng xếp hạng tìm kiếm nếu bạn sử dụng HTTPS, cho lợi ích SEO này quá. Có một thanh để đi với cà rốt mặc dù: Chrome và các trình duyệt khác đang có kế hoạch đưa ra các cảnh báo lớn hơn và lớn hơn trên tất cả các trang web mà không làm điều này, bắt đầu từ tháng 1 năm 2017. HTTP không an toàn đang trên đường ra, và bây giờ là thời gian để nâng cấp.


Đã sử dụng HTTPS ở mọi nơi? Đi tiếp và xem xét thiết lập HTTP Strict Transport Security (HSTS), một tiêu đề dễ dàng mà bạn có thể thêm vào phản hồi của máy chủ để không cho phép HTTP không an toàn cho toàn bộ miền của bạn.

9. Công cụ bảo mật trang web

Một khi bạn nghĩ rằng bạn đã làm tất cả những gì bạn có thể thì đó là thời gian để thử nghiệm bảo mật trang web của bạn. Cách hiệu quả nhất để làm việc này là thông qua việc sử dụng một số công cụ bảo mật trang web, thường được gọi là thử nghiệm thâm nhập hoặc kiểm tra bút ngắn.

Có rất nhiều sản phẩm thương mại và miễn phí để giúp bạn với việc này. Chúng hoạt động trên cơ sở tương tự như các tập lệnh mà các hacker sẽ sử dụng để kiểm tra tất cả các hành vi khai thác và cố gắng làm tổn hại đến trang web của bạn bằng cách sử dụng một số phương pháp đã đề cập trước đó như SQL injection.


Một số công cụ miễn phí đáng xem:



  • Netsparker (phiên bản cộng đồng miễn phí và phiên bản dùng thử có sẵn). Tốt cho thử nghiệm SQL injection và XSS

    • OpenVAS . Yêu cầu phải là trình quét mã bảo mật mã nguồn mở tiên tiến nhất. Tốt cho việc kiểm tra các lỗ hổng đã biết, hiện đang quét trên 25.000. Nhưng nó có thể khó thiết lập và yêu cầu một máy chủ OpenVAS được cài đặt mà chỉ chạy trên * nix. OpenVAS là một phần của Nessus trước khi nó trở thành một sản phẩm thương mại mã nguồn đóng.
    • SecurityHeaders.io (kiểm tra trực tuyến miễn phí). Công cụ để nhanh chóng báo cáo tiêu đề bảo mật đã đề cập ở trên (chẳng hạn như CSP và HSTS) đã bật và cấu hình một tên miền chính xác.
    • Xenotix XSS Exploit Framework Một công cụ của OWASP (Open Web Application Security Project) bao gồm một loạt các ví dụ tấn công XSS rất lớn mà bạn có thể chạy để nhanh chóng xác nhận liệu các đầu vào của trang web có dễ bị tổn thương trong Chrome, Firefox và IE hay không.

    Kết quả từ các bài kiểm tra tự động có thể gây khó chịu, vì chúng thể hiện rất nhiều vấn đề tiềm ẩn. Điều quan trọng là phải tập trung vào các vấn đề quan trọng trước tiên. Mỗi vấn đề báo cáo thường đi kèm với một giải thích tốt về tiềm năng dễ bị tổn thương. Có thể bạn sẽ thấy rằng một số vấn đề trung bình / thấp không phải là mối quan tâm đối với trang web của bạn.

    Nếu bạn muốn tiến thêm một bước nữa thì có một số bước tiếp theo bạn có thể thực hiện để cố gắng thỏa hiệp trang web bằng cách thay đổi giá trị POST / GET. Một proxy gỡ lỗi có thể giúp bạn ở đây vì nó cho phép bạn đánh chặn các giá trị của một yêu cầu HTTP giữa trình duyệt và máy chủ của bạn. Một ứng dụng phần mềm miễn phí phổ biến được gọi là Fiddler là một điểm khởi đầu tốt.

    Vậy bạn nên cố gắng làm gì để thay đổi theo yêu cầu? Nếu bạn có các trang chỉ hiển thị cho người dùng đã đăng nhập thì tôi sẽ cố gắng thay đổi các thông số URL như id người dùng hoặc các giá trị cookie để xem chi tiết của người dùng khác. Một khu vực đáng kiểm tra khác là các biểu mẫu, thay đổi giá trị POST để cố gắng gửi mã để thực hiện XSS hoặc để tải lên một kịch bản phía máy chủ.

    Hy vọng rằng những lời khuyên này sẽ giúp giữ cho trang web và thông tin của bạn an toàn. Cám ơn rất nhiều CMS có rất nhiều tính năng bảo mật trang web sẵn có, nhưng vẫn là một ý tưởng tốt để có kiến ​​thức về các lỗ hổng bảo mật phổ biến nhất để bạn có thể đảm bảo bạn được bảo vệ.

    Ngoài ra còn có một số mô đun hữu ích sẵn có cho CMSes để kiểm tra cài đặt của bạn cho các lỗi bảo mật thông thường như Xem lại an toàn cho Drupal và WP Security Scan for WordPress.

    XEM THÊM : 

    0 nhận xét:

    Post a Comment