Một số phương pháp bảo mật bảo vệ website của bạn tránh khỏi Hacker

Có thể bạn nghĩ rằng, trang web của bạn không có bất kỳ thông tin có giá trị nào để mà bị tin tặc (hacker) tấn công, nhưng bạn đã nhầm, các trang web bị xâm nhập mọi lúc. Phần lớn các xâm nhập an ninh web này không phải là để ăn cắp dữ liệu hoặc phá hỏng website của bạn. Thay vào đó, tin tặc cố gắng sử dụng máy chủ của bạn như là một địa chỉ email để gửi thư rác hoặc sử dụng máy chủ của bạn để 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 tấn công rất phổ biến này nhìn chung là nhằm mục đích lạm dụng các máy chủ bị xâm nhập, sử dụng chúng như một phần của một mạng botnet (mạng lưới các máy tính cá nhân bị nhiễm phần mềm độc hại và được điều khiển theo nhóm mà không hề biết, ví dụ như lợi dụng để gửi thư rác), hoặc mỏ cho Bitcoin. Thậm chí bạn có thể bị nhiễm ransomware - một loại phần mềm độc hại được thiết kế để chặn truy cập vào hệ thống máy tính cho đến khi một khoản tiền được trả.

Hacker thực hiện hack thường xuyên bằng các script tự động được viết để quét Internet nhằm cố gắng khai thác những vấn đề về bảo mật trang web đã biết trong phần mềm. Dưới đây là một số tip giúp bạn và trang web của bạn an toàn hơn trên mạng.

1. Keep software up to date (Cập nhật phần mềm thường xuyên)

Điều này có vẻ như là hiển nhiên, nhưng việc đảm bảo tất cả phần mềm được cập nhật là rất 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 đang chạy trên trang web của bạn, ví dụ như một CMS hoặc diễn đàn. Khi tìm thấy lỗ hổng bảo mật của trang web 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ữ (hosting) thì bạn không cần phải lo lắng quá 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 hosting sẽ lo điều 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 ví dụ như một CMS hoặc diễn đàn, bạn nên đảm bảo rằng bạn có thể nhanh chóng áp dụng bất kỳ phần bảo mật nào. Hầu hết các nhà cung cấp đều có một danh sách gửi thư hoặc RSS feed nêu rõ bất kỳ vấn đề bảo mật nào trên trang web. 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 có sẵn khi bạn đăng nhập.

Nhiều developer sử dụng các tool như Composer, npm, hoặc RubyGems để quản lý các phụ thuộc phần mềm của họ, các lỗ hổng bảo mật có thể xuất hiện trong 1 package nào đó trong đây. Các lỗ hổng bảo mật nào đã bị công bố của hệ điều hành, máy chủ Web, máy chủ ứng dụng và các phần mềm của hãng thứ ba khác thì hầu hết đều có phần sửa lỗi bổ sung, tuy vậy những hệ thống không được cập nhật thường xuyên sẽ là miếng mồi ngon cho hacker. Chính vì vậy hãy luôn đảm bảo rằng phần mềm/ hệ thống của bạn được cập nhật thường xuyên, bạn cũng có thể sử dụng các tool thông báo tự động khi xuất hiện lỗ hổng bảo mật để kiểm soát lỗi, ví dụ như Gemnasium

2. SQL injection

SQL injection là một kỹ thuật cho phép những kẻ tấn công lợi dụng lỗ hổng của việc kiểm tra dữ liệu đầu vào trong các ứng dụng web và các thông báo lỗi của hệ quản trị cơ sở dữ liệu trả về để inject (tiêm vào) và thi hành các câu lệnh SQL bất hợp pháp (chèn các câu lệnh SQL bất hợp pháp vào 1 input field của form trên trang web hoặc vào param URL, nhằm mục đích truy cập hoặc thao tác trên cơ sở dữ liệu của bạn). SQL injection có thể cho phép những kẻ tấn công thực hiện các thao tác như một người quản trị web như delete, insert, update,… trên cơ sỡ dữ liệu của ứng dụng, thậm chí là server mà ứng dụng đó đang chạy. Lỗi này thường xảy ra trên các ứng dụng web có dữ liệu được quản lý bằng các hệ quản trị cơ sở dữ liệu như SQL Server, MySQL, Oracle, DB2, Sysbase…

SQL Injection là một trong những lớp ứng dụng phổ biến nhất tại các cuộc tấn công đang được sử dụng trên Internet. Mặc dù thực tế rằng tương đối dễ dàng để chống lại SQL Injection, nhưng vẫn có số lượng lớn các trang web đối mặt với nguy cơ bị tấn công injection. Khi bạn sử dụng các câu giao dịch truy vấn chuẩn (standard Transact SQL) bạn sẽ rất dễ vô tình chèn các mã rogue vào truy vấn của bạn, các mã này có thể được sử dụng để thay đổi bảng, lấu thông tin và xóa dữ liệu trong DB. Bạn có thể dễ dàng phòng tránh điều này bằng cách sử dụng các câu truy vấn đã được tham số hóa (parameterised queries), hầu hết các ngôn ngữ lập trình web đều có tính năng này và dễ dàng sử dụng.

Do gần đây các khái niệm framework đã và đang được sử dụng rất nhiều. Các framework đều đã được test cẩn thận để phòng tránh các lỗi, trong đó có SQL Injection nên các lỗi SQL injection đã được giảm đi nhiều.

2.1. Ví dụ tấn công

Hãy xem truy vấn sau:

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

Nếu kẻ tấn công thay đổi điều kiện truy vấn bằng cách thay param bằng OR '1'='1' để có 1 câu truy vấn luôn luôn đúng:

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

-Và nó sẽ còn tệ hại hơn khi mà người dùng chèn thêm một câu lệnh truy vấn phía sau:

SELECT * FROM table WHERE column = ' ' OR '1'='1'; Drop table users;

Các bạn nhìn vào thì đủ biết chuyện gì sẽ xảy ra đúng không nào.

2.2. Cách phòng chống

Cách phòng trống đối với dạng này thì cũng khá đơn giản. Các bạn chỉ cần ràng buộc thật kỹ dữ liệu người dùng nhập vào và luôn luôn phải có quan điểm 'Đừng bao giờ tin vào những thứ người dùng nhập vào là đúng'.

Luôn ràng buộc kiểu dữ liệu Trong ứng dụng thì bạn luôn phải nhớ ràng buộc dữ liệu thật cẩn thận. VD: Như đối với phương thức get url: http://domain.com?id=5.

//Thông thường
$id = $_GET['id'];
//Ràng buộc cẩn thận
$id = isset($_GET['id'])?(string)(int)$_GET['id']:false;

Regular Expression Hoặc bạn có thể dùng Regular Expression để loại bỏ đi các ký tự lạ hoặc các ký tự cấm. Ví dụ trên:

$id = isset($_GET['id']) ? $_GET['id'] : false;
$id = str_replace('/[^0-9]/', ', $id);

Dùng các hàm có sẵn để giảm thiểu lỗi. Mỗi khi truy vấn thì mọi người nên sử dụng thêm hàm mysqli_real_escape_string để chuyển đổi một chuỗi thành một query an toàn. Ví dụ:

$id = isset($_GET['id'])?(string)(int)$_GET['id']:false;
$sql= 'SELECT * FROM tbl_user WHERE id= ' . mysqli_real_escape_string($id);

Để đảm bảo tránh được 100% các lỗi liên quan đến SQL injection thì bạn nên sử dụng các framework thay vì code thuần.

3. XSS (Cross-Site Scripting)

Cross-site Scripting (XSS) là lỗ hổng bảo mật cho phép hacker có thể chèn những đoạn mã client-script (thường là Javascript hoặc HTML) vào trang web, khi người dùng vào những trang web này, mã độc sẽ được thực thi trên máy của người dùng (Nói cách khác XSS là một kỹ thuật tấn công buộc 1 trang Web phải hiển thị các đoạn mã độc, sau đó các mã này sẽ được thực thi trên trình duyệt web của người dùng nhờ vào mã javascript, nhằm mục đích thay đổi nội dung trang hoặc ăn cắp thông tin để gửi lại cho kẻ tấn công). Khác với SQL Injection tấn công vào CSDL của website, XSS tấn công trực tiếp vào người dùng. Lợi dụng lỗi XSS, hacker có thể lừa đảo quản trị của website, ăn cắp cookie, chiếm sesion… từ đó có thể đăng nhập chiếm quyền điều khiển website. Ví dụ : bạn có 1 bài đăng và các bình luận trong 1 trang web không có validation thì kẻ tấn công có thể vào gửi các bình luận có chứa các thẻ script hoặc các lệnh Javascript. Chúng có thể chạy khắp nơi 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 tất cả những người dùng đã xem bình luận chứa mã độc đó. Để ngăn chặn điều này, bạn cần đảm bảo rằng người dùng không thể đưa bất kỳ nội dung JavaScript nào 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à đa phần là HTML- sau này được thông dịch sang các framework front-end như Angular và Ember. Các framework này cung cấp nhiều biện pháp bảo vệ XSS, nhưng sự qua lại giữa máy chủ và client lại tạo ra các tuyến tấn công mới và phức tạp hơn : không đơn thuần chỉ là tiêm JavaScript vào HTML, mà 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 helpers.

Cách khắc phục : Người ta không lường hết được mức độ nguy hiểm của XSS nhưng cũng không quá khó khăn để ngăn ngừa XSS. Giống như SQL Injection, bản chất của lỗi XSS là không kiểm soát kỹ dữ liệu nhập đầu vào, vì thế biện pháp hiệu quả nhất là kiểm tra kỹ dữ liệu nhập vào từ người dùng, chặn các từ khóa nguy hiểm, chỉ chấp nhận những dữ liệu hợp lệ.

Một trong những cách khác hay sử dụng mà không cần kiểm soát đầu vào từ người dùng là mã hoá các kí tự đặc biệt trước khi in ra website, nhất là những gì có thể gây nguy hiểm cho người sử dụng. Để phòng chống XSS tốt nhất là theo nguyên tắc FIEO (Filter Input, Escape Output). Để làm việc này thì hiện tại có khá nhiều bộ lọc để chúng ta lựa chọn. Ví dụ bộ thư viện viết bằng PHP cho phép filter HTML để ngăn chặn kẻ xấu post mã độc XSS thông qua website của bạn.

• Viết mã lọc nội dung theo nguyên tắc FIEO (Filter Input, Escape Output) - vì các đoạn mã độc bắt đầu với “<script>” và kết thúc với “</script>” . Thay : “<” và “>” = & gt; và & lt; (các thực thể html) như vậy nó sẽ vẫn được in ra màn hình đúng định dạng mà không hề gây nguy hiểm cho người sử dụng.Ta có đoạn code sau :

str_replace("<","&gt;",$info);str_replace(">","&lt;",$info);str_replace("'","&apos;",$info);str_replace(""","&quot;",$info);
str_replace("&","&amp;",$info);  

• Mã hóa các ký tự đặc biệt của HTML với hàm htmlentities()

include("../../connect.php");
$query = "select * from message order by time desc";
$result = mysql_query($query);
$numRow = mysql_num_rows($result);
if ($numRow != 0){
 while($row = mysql_fetch_array($result))
 echo $row["content"];
}

Ta thấy ở đoạn code trên biến $row["content"] được in trực tiếp ra mà không qua xử lý. Trường content được nhập vào từ người dùng nên đoạn code này chắc chắn có lỗi XSS. Để khắc phục ta sẽ mã hóa các ký tự đặc biệt của HTML với hàm htmlentities(). Mã nguồn được chỉnh sửa lại như sau:

echo htmlentities($$ow["content"]);

• Dùng thư viện có sẵn : HTML Purifier Nói sơ qua về HTML Purifier thì đây là bộ thư viện rất mạnh dùng triển khai trong code để chống XSS. Được xây dựng theo mô hình OOP nên sử dụng rất dễ, sau thao tác include file thư viện, chỉ cần tạo instance của đối tượng HTML Purifier và gọi phương thức purify() là có thể filter được dữ liệu đầu vào.

phprequire_once '/path/to/htmlpurifier/library/HTMLPurifier.auto.php';$purifier = new HTMLPurifier();$clean_html = $purifier->purify($dirty_html);

4. Error messages (Thông báo lỗi)

Hãy cẩn thận với lượng thông tin bạn đưa ra trong các thông báo lỗi của mình. Chỉ nên cung cấp lỗi nhỏ cho người dùng, để đảm bảo rằng họ không làm rỏ rỉ bí mật trên máy chủ của bạn (ví dụ như các key API hoặc các password của DB). Không cung cấp đầy đủ chi tiết ngoại lệ 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 trở nên dễ dàng hơn. Giữ các lỗi chi tiết trong nhật ký server và chỉ cung cấp cho user thông tin họ cần.

5. Server side validation/form validation

Validation nên được thực hiện ở cả bên trình duyệt (validate dưới client/user - UI) và server side (server). Phía trình duyệt có thể bắt các lỗi đơn giản như bỏ trống ở các trường bắt buộc hoặc nhập văn bản vào một trường yêu cầu số. Tuy nhiên có thể vẫn sẽ bỏ sót lỗi (mã độc pass), vì vậy bạn cần phải thực hiện validation sâu hơn ở phía máy chủ vì không thực hiện như vậy 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. Tuy vậy, việc đã thực hiện validation ở bên trình duyệt trước rồi cũng sẽ giảm tải công việc cho bên server.

6. Password

Ai cũng biết là nên sử dụng mật khẩu phức tạp thì sẽ bảo mật tốt hơn nhưng không phải ai cũng làm điều đó. Sử dụng mật khẩu mạnh (strong password) ở server và admin là điều rất quan trọng nhưng việc sử dụng mật khẩu mạnh cho người dùng cũng quan trọng không kém để bảo mật tài khoản người dùng được tốt hơn. Nhiều người dùng có thể không thích strong password này vì nó gây ra sự khó khăn trong việc đăng ký hoặc khó để nhớ nhưng mà nó sẽ giúp bảo vệ thông tin trong thời gian dài. Một số yêu cầu có thể gặp để có được 1 strong password : phải lớn hơn hoặc bằng 8 ký tự, có ít nhất 1 chữ in hoa, có ít nhất 1 chữ số, có ít nhất 1 ký tự đặc biệt, bắt đầu bằng ký tự đặc biệt ....

Mật khẩu phải luôn được lưu trữ dưới dạng các giá trị đã được mã hóa, tốt hơn cả là sử dụng thuật toán hàm băm (hash) 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 tốt hơn, bạn nên hash password bằng salt để khắc phục weak password. Người dùng có thể chọn một mật khẩu yếu, đó là chuyện bình thường. Tuy nhiên, là người xây dựng hệ thống các bạn cần phải khắc phục điều này. Giải pháp là sử dụng thêm một chuỗi mà thường được gọi là salt. Hiểu đơn giản như thế này : trong cấu hình của ứng dụng, các bạn lưu trữ một chuỗi (phức tạp dài dòng) được gọi là salt. Trước khi lưu trữ mật mã vào cơ sở dữ liệu chúng ta thực hiện việc kết hợp salt với mật mã. Có nhiều kiểu kết hợp khác nhau, đơn giản nhất là nối chúng lại (ví dụ với PHP):

$crypPassword=md5($rawPassword.$$alt);

Sau đó mật mã mới này được lưu vào cơ sở dữ liệu. Khi đó, dù ai đó có toàn bộ dữ liệu của chúng ta cũng không dễ dàng để dò ra mật khẩu dựa vào weak password dictionary được. Ngoài ra, có thể làm cho hệ thống tốt hơn bằng việc sử dụng salt duy nhất cho mỗi mật mã. Thông thường hệ thống sẽ có rất nhiều thành viên, và việc các thành viên dùng mật khẩu giống nhau là phổ biến. Hãy đặt tình huống hacker có cả hai thông tin là dữ liệu và salt. Nếu chúng ta sử dụng một salt duy nhất, khi ấy tất cả các tài khoản dùng chung mật mã thì mật mã được mã hóa (crypPassword) đều sẽ giống nhau. Kẻ tấn công sẽ chỉ cần brute force một trong số đó là cũng có các tài khoản còn lại mà không tốn thêm công sức gì. Để tránh rủi ro này và làm tăng thêm khó khăn cho kẻ tấn công, hệ thống nên sử dụng các salt duy nhất cho mỗi mật mã. Lúc ấy, mỗi crypPassword sẽ là khác nhau và tất nhiên hacker sẽ không có được danh sách các tài khoản có mật mã giống nhau. Trường hợp xấu nhất là một kẻ tấn công nào đó sẽ làm một cuộc tấn công bằng từ điển hoặc tấn công brute force, về cơ bản nó sẽ đoán (dò) mọi sự kết hợp cho đến khi nó tìm thấy một match (kết quả). Hacker sẽ phải brute force từng tài khoản một -> rất khó khăn cho việc tính toán + dò mật khẩu. Có nhiều cách để tạo salt độc nhất. Việc này sẽ dễ dàng nếu bạn có kiến thức về các hàm entropy trong ngôn ngữ lập trình đang dùng.

Nhiều CMS cung cấp cho người dùng quản lý với rất nhiều tính năng bảo mật trang web đã được xây dựng bên trong nó, mặc dù một số module cấu hình hoặc module mở rộng có thể được yêu cầu sử dụng password đã được salt hoặc đã thiết lập mật khẩu mạnh tối thiểu. 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ì cấu hình của chúng có sẵn bảo mật trang web và cung cấp các điều khiển readymade để đăng nhập và đặt lại mật khẩu.

7. File uploads

Cho phép người dùng tải file lên trang web của bạn có thể là nguy cơ gây rủi ro lớn cho bảo mật trang web, ngay cả khi chỉ là tính năng đơn giản như thay đổi avatar của người dùng. Rủi ro ở đây là có tệp tin nào đó được tải lên nhìn tưởng chừng như vô hại nhưng có thể có thể chứa một script mà khi thực hiện trên máy chủ sẽ mở ra trang web của bạn. Ví dụ như : khi người dùng của bạn tải lên 1 file ảnh, bạn không thể chỉ dựa vào extension hoặc mime type của file đó để xác minh rằng file đó là một file ảnh vì chúng có thể dễ bị giả mạo. Thậm chí ngay cả khi bạn mở tệp tin và đọc phần header hoặc sử dụng các hàm kiểm tra kích thước ảnh thì cũng không phải là bằng chứng đầy đủ. Hầu hết các định dạng ảnh đều cho phép lưu trữ một phần comment, phần comment này có thể sẽ chứa mã độc và được thực hiện trên server.

Vậy làm sao để ngăn chặn điều này? Theo mặc định, các máy chủ web sẽ không thực thi các file có extension là ảnh nhưng cũng không nên chỉ dựa vào việc kiểm tra phần extension của file. Một số tùy chọn là đổi tên tệp khi tải lên để đảm bảo phần extension của tệp là chính xác hoặc để thay đổi quyền truy cập tệp, 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 sẽ chỉ cho phép truy cập vào tập các file, ngăn chặn cuộc tấn công extension kép được đề cập trước đó.

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

Nên lưu trữ các ảnh được tải lên ở một thư mục bên ngoài webroot hoặc trong cơ sở dữ liệu dưới dạng blob. Không thể truy cập trực tiếp tới các file này, bạn cần phải tạo một script để fetch 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. Các thẻ ảnh hỗ trợ thuộc tính scr chứ không phải là URL trực tiếp vào image, src 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 dịch vụ lưu trữ đều phả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ó vài điều bạn sẽ muốn kiểm tra. Đảm bảo rằng 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 DMZ (Demilitarised Zone) 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 phải 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 được tải lên từ Internet thì chỉ nên 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ơ 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à không thể truy cập trực tiếp máy chủ cơ sở dữ liệu 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 nhìn thấy khi chuyển tiếp. Nếu có bất cứ thứ gì mà người dùng của bạn muốn riêng tư, bạn chỉ nên sử dụng HTTPS để phân phối nó. Tất nhiên điều này có nghĩa là áp dụng cho thẻ tín dụng và các trang đăng nhập (và URL mà họ gửi đến). Ví dụ một form đăng nhập thường sẽ thiết lập một cookie sẽ đượ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 tạo ra và được sử dụng để xác thực các yêu cầu đó. Một kẻ tấn công ăn cắp được thông tin này sẽ có thể bắt chước (giả mạo) 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 để Encrypt cung cấp các xác nhận hoàn toàn miễn phí và tự động, bạn sẽ cần HTTPS, các tool cộng đồng hiện có sẵn cho một loạt các nền tảng và framework chung để tự động thiết lập điều này cho bạn.

9. Website security tools

Bận có thể bảo mật cho trang web của mình bằng cách sử dụng một số tool bảo mật trang web. Có rất nhiều sản phẩm thương mại và miễn phí để giúp bạn 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ử dụng để kiểm tra tất cả các hành vi khai thác và cố gắng thỏa hiệp trang web của bạn bằng cách sử dụng một số phương pháp đã đề cập trước đó chẳng hạn như SQL injection. Một số tool miễn phí như:

• Netsparker : tốt cho kiểm tra SQL injection và XSS
• OpenVAS
• SecurityHeaders.io (free online check)
• Others

Lời kết

Còn rất nhiều các loại tấn công khác và các cách phòng chống khác nhau mà không đề cập trong bài. Có gì thiếu sót mong mọi người góp ý thêm (yeah)

Link tham khảo

• http://www.creativebloq.com/web-design/website-security-tips-protect-your-site-7122853
• Các nguồn khác