Hiểu cách các cuộc tấn công SQL Injection (hoặc SQLi) thao tác các truy vấn SQL để gây ra thiệt hại. Xem các cuộc tấn công trong đời thực, các ví dụ về tấn công và 4 biện pháp phòng thủ.

Bạn đang xem : cách thực hiện một cuộc tấn công tiêm sql

Tấn công SQL Injection là gì?

Các cuộc tấn công SQL Injection (hoặc SQLi) thay đổi các truy vấn SQL, tiêm mã độc hại bằng cách khai thác các lỗ hổng ứng dụng.

Các cuộc tấn công SQLi thành công cho phép kẻ tấn công sửa đổi thông tin cơ sở dữ liệu, truy cập dữ liệu nhạy cảm, thực thi các tác vụ quản trị trên cơ sở dữ liệu và khôi phục tệp từ hệ thống. Trong một số trường hợp, những kẻ tấn công có thể ra lệnh cho hệ điều hành cơ sở dữ liệu bên dưới.

Tác động của việc đưa vào SQL đối với các ứng dụng của bạn:

  • Ăn cắp thông tin đăng nhập — người đánh dấu có thể lấy thông tin đăng nhập thông qua SQLi, sau đó mạo danh người dùng và sử dụng các đặc quyền của họ.
  • Truy cập cơ sở dữ liệu — người dùng tấn công có thể có quyền truy cập vào dữ liệu nhạy cảm trong máy chủ cơ sở dữ liệu.
  • Thay đổi dữ liệu —công cụ ghi nhớ có thể thay đổi hoặc thêm dữ liệu mới vào cơ sở dữ liệu được truy cập.
  • Xóa dữ liệu —công cụ đóng gói có thể xóa các bản ghi cơ sở dữ liệu hoặc xóa toàn bộ bảng.
  • Di chuyển bên —công cụ gắn kết có thể truy cập vào máy chủ cơ sở dữ liệu với các đặc quyền của hệ điều hành và sử dụng các quyền này để truy cập các hệ thống nhạy cảm khác.

Bạn muốn biết cách tránh đưa SQL vào mã của mình? Xem phiên bản ngắn của bảng gian lận ngăn chặn tiêm vào SQL OWASP của chúng tôi.

Đây là một phần của loạt hướng dẫn sâu rộng về bảo mật dữ liệu .

Trong bài viết này, bạn sẽ tìm hiểu:

Real-Life SQL Injection Attack Examples

Trong 20 năm qua, nhiều cuộc tấn công SQL injection đã nhắm mục tiêu vào các trang web lớn, doanh nghiệp và nền tảng truyền thông xã hội. Một số cuộc tấn công đã dẫn đến vi phạm dữ liệu nghiêm trọng. Một vài ví dụ đáng chú ý được liệt kê bên dưới.

Vi phạm được Kích hoạt bởi SQL Injection

  • Cuộc tấn công GhostShell —hackers from APT group Team GhostShell đã nhắm mục tiêu vào 53 trường đại học sử dụng SQL injection, đánh cắp và xuất bản 36.000 hồ sơ cá nhân của sinh viên, giảng viên và nhân viên.
  • Chính phủ Thổ Nhĩ Kỳ —một nhóm APT khác, RedHack, đã sử dụng SQL injection để xâm phạm trang web của chính phủ Thổ Nhĩ Kỳ và xóa nợ cho các cơ quan chính phủ.
  • vi phạm 7-Eleven —một nhóm kẻ tấn công đã sử dụng SQL injection để xâm nhập vào hệ thống công ty tại một số công ty, chủ yếu là 7 – Chuỗi cửa hàng bán lẻ, đánh cắp 130 triệu số thẻ tín dụng.
  • Vi phạm HBGary —các kẻ tấn công liên quan đến nhóm hoạt động Anonymous đã sử dụng SQL Injection để gỡ trang web của công ty bảo mật CNTT. Cuộc tấn công là một phản ứng đối với việc Giám đốc điều hành HBGary công khai rằng ông có tên của các thành viên tổ chức Ẩn danh.

Lỗ hổng SQL Injection đáng chú ý

  • Lỗ hổng Tesla —năm 2014, các nhà nghiên cứu bảo mật đã công khai rằng họ có thể xâm nhập trang web của Tesla bằng cách sử dụng SQL injection, giành được đặc quyền quản trị và lấy cắp dữ liệu của người dùng.
  • Lỗ hổng của Cisco —năm 2018, một lỗ hổng SQL injection đã được tìm thấy trong Trình quản lý Giấy phép Prime của Cisco. Lỗ hổng cho phép những kẻ tấn công có được quyền truy cập shell vào các hệ thống mà trình quản lý giấy phép đã được triển khai. Cisco đã vá lỗ hổng bảo mật.
  • Lỗ hổng trong Fortnite —Fortnite là một trò chơi trực tuyến với hơn 350 triệu người dùng. Vào năm 2019, một lỗ hổng SQL injection đã được phát hiện có thể cho phép những kẻ tấn công truy cập vào tài khoản người dùng. Lỗ hổng bảo mật đã được vá.

Các kiểu tấn công SQL Injection

Có một số kiểu chèn SQL:

  • Truyền SQL dựa trên liên minh – SQL Injection dựa trên liên minh đại diện cho kiểu tiêm SQL phổ biến nhất và sử dụng câu lệnh UNION. Câu lệnh UNION đại diện cho sự kết hợp của hai câu lệnh select để truy xuất dữ liệu từ cơ sở dữ liệu.
  • Truyền SQL dựa trên lỗi – phương pháp này chỉ có thể chạy trên Máy chủ MS-SQL. Trong cuộc tấn công này, người dùng độc hại khiến một ứng dụng hiển thị lỗi. Thông thường, bạn hỏi cơ sở dữ liệu một câu hỏi và nó trả về một thông báo lỗi cũng chứa dữ liệu mà họ yêu cầu.
  • Blind SQL Injection – trong cuộc tấn công này, không có thông báo lỗi nào được nhận từ cơ sở dữ liệu; Chúng tôi trích xuất dữ liệu bằng cách gửi các truy vấn đến cơ sở dữ liệu. Việc tiêm SQL mù có thể được chia thành SQL Injection dựa trên boolean và SQL Injection dựa trên thời gian. Tìm hiểu thêm trong hướng dẫn của chúng tôi về Đưa vào SQL mù .

Các cuộc tấn công SQLi cũng có thể được phân loại theo phương pháp chúng sử dụng để đưa dữ liệu vào:

  • Đưa vào SQL dựa trên thông tin nhập của người dùng – ứng dụng web chấp nhận đầu vào thông qua biểu mẫu, mà chuyển đầu vào của người dùng vào cơ sở dữ liệu để xử lý. Nếu ứng dụng web chấp nhận các đầu vào này mà không cần khử trùng chúng, kẻ tấn công có thể đưa các câu lệnh SQL độc hại vào.
  • Chèn SQL dựa trên cookie – một cách tiếp cận khác để đưa vào SQL là sửa đổi cookie thành “độc ”Truy vấn cơ sở dữ liệu. Các ứng dụng web thường tải cookie và sử dụng dữ liệu của chúng như một phần của hoạt động cơ sở dữ liệu. Người dùng độc hại hoặc phần mềm độc hại được triển khai trên thiết bị của người dùng, có thể sửa đổi cookie, để đưa vào SQL theo cách không mong muốn.
  • Chèn SQL dựa trên tiêu đề HTTP – biến máy chủ như tiêu đề HTTP cũng có thể được sử dụng cho SQL injection. Nếu một ứng dụng web chấp nhận đầu vào từ các tiêu đề HTTP, thì các tiêu đề giả có chứa SQL tùy ý có thể đưa mã vào cơ sở dữ liệu.
  • Chèn SQL bậc hai – đây có thể là cách đưa vào SQL phức tạp nhất các cuộc tấn công, bởi vì chúng có thể nằm im trong một thời gian dài. Một cuộc tấn công chèn SQL bậc hai cung cấp dữ liệu bị nhiễm độc, có thể được coi là lành tính trong một ngữ cảnh, nhưng lại độc hại trong một ngữ cảnh khác. Ngay cả khi các nhà phát triển làm sạch tất cả các đầu vào của ứng dụng, họ vẫn có thể dễ bị tấn công bởi kiểu tấn công này.
Xem Thêm  Tải lên tệp bằng HTML - tải tệp html lên máy chủ

Bảo mật ứng dụng của bạn với mọi bản dựng

Đăng ký tài khoản Bright MIỄN PHÍ .

Các ví dụ về mã SQL Injection

Hãy xem xét hai ví dụ phổ biến về các cuộc tấn công SQL injection.

Ví dụ 1: Sử dụng SQLi để xác thực với tư cách quản trị viên

Ví dụ này cho thấy cách kẻ tấn công có thể sử dụng SQL injection để phá vỡ xác thực của ứng dụng và giành được đặc quyền của quản trị viên.

Hãy xem xét một hệ thống xác thực đơn giản sử dụng bảng cơ sở dữ liệu với tên người dùng và mật khẩu. Yêu cầu POST của người dùng sẽ cung cấp các biến user pass và các biến này được chèn vào một câu lệnh SQL:

sql = "SELECT id TỪ người dùng WHERE tên người dùng = '"+ người dùng +" "VÀ mật khẩu ='" + pass + "" "

Vấn đề ở đây là câu lệnh SQL sử dụng phép nối để kết hợp dữ liệu. Kẻ tấn công có thể cung cấp một chuỗi như thế này thay vì biến pass :

password 'OR 5 = 5

Kết quả Truy vấn SQL sẽ được chạy trên cơ sở dữ liệu:

CHỌN id TỪ người dùng WHERE username = 'user' AND password = 'pass' OR 5 = 5 '

5 = 5 là một điều kiện luôn đánh giá là true, toàn bộ câu lệnh WHERE sẽ là true, bất kể tên người dùng hoặc mật khẩu được cung cấp.

Câu lệnh WHERE sẽ trả về ID đầu tiên từ bảng người dùng, thường là quản trị viên. Điều này có nghĩa là kẻ tấn công có thể truy cập ứng dụng mà không cần xác thực và cũng có đặc quyền của quản trị viên.

Một hình thức nâng cao hơn của cuộc tấn công này là nơi kẻ tấn công thêm một ký hiệu chú thích mã vào cuối câu lệnh SQL, cho phép chúng thao tác sâu hơn với truy vấn SQL. Phần sau sẽ hoạt động trong hầu hết các cơ sở dữ liệu bao gồm MySQL, PostgreSQL và Oracle:

'OR' 5 '=' 5 '/ *

Ví dụ 2: Sử dụng SQLi để truy cập dữ liệu nhạy cảm

Trong ví dụ này, đoạn mã sau lấy tên người dùng hiện tại và tìm kiếm các mục khớp với một tên mục nhất định, trong đó chủ sở hữu là người dùng hiện tại.

...
string userName = ctx.getAuthenticatedUserName ();
string query = "SELECT * FROM items WHERE owner =" '"
+ userName +" 'AND itemname =' "
+ ItemName.Text +" '";
...

Đoạn mã này có điểm yếu giống như trong ví dụ trước – sử dụng nối. Sau khi kết hợp tên người dùng và tên mục, mã sẽ tạo truy vấn sau:

CHỌN * TỪ mục
WHERE chủ sở hữu =
VÀ tên mục =;

Nếu kẻ tấn công cung cấp chuỗi sau cho itemname :

Widget 'HOẶC 5 = 5

Câu lệnh SQL trở thành:

CHỌN * TỪ các mục
WHERE owner = 'John'
AND itemname = 'Widget' OR 5 = 5 ';

Giống như: CHỌN * TỪ các mục;

Điều này có nghĩa là truy vấn sẽ trả về dữ liệu của toàn bộ bảng, cho phép kẻ tấn công truy cập trái phép vào dữ liệu nhạy cảm.

Ví dụ 3: Chèn các câu lệnh độc hại vào trường biểu mẫu

Đây là một cuộc tấn công đưa vào SQL đơn giản dựa trên đầu vào của người dùng. Kẻ tấn công sử dụng một biểu mẫu yêu cầu tên và họ làm đầu vào. Kẻ tấn công nhập:

  • Tên: malware'ex
  • Họ: Smith
  • < / ul>

    Biến tên của kẻ tấn công chứa một biểu thức độc hại, chúng tôi đã ký hiệu là ‘ex. Câu lệnh SQL xử lý các đầu vào biểu mẫu trông giống như sau:

    CHỌN id, tên, họ TỪ các tác giả

    Khi kẻ tấn công đưa một biểu thức độc hại vào tên, câu lệnh sẽ trông giống như sau:

    SELECT id, firstname, lastname TỪ các tác giả WHERE firstname = 'malware'ex' và lastname = 'newman'

    Cơ sở dữ liệu xác định cú pháp không chính xác do dấu nháy đơn và cố gắng thực thi câu lệnh độc hại.

    Để biết thêm nhiều ví dụ về SQL độc hại mã, hãy xem hướng dẫn chi tiết của chúng tôi về Chèn SQL payloads .

    SQL Injection Prevention Cheat Sheet

    Đây là phiên bản tóm tắt của ngăn chặn tiêm SQL OWASP xuất sắc cheat sheet .

    Phòng thủ Tùy chọn 1: Câu lệnh chuẩn bị (với Truy vấn tham số) < / h3>

    Các câu lệnh soạn sẵn rất dễ học và sử dụng, đồng thời loại bỏ vấn đề của SQL injection. Chúng buộc bạn phải xác định mã SQL và chuyển từng tham số cho truy vấn sau đó, tạo ra sự khác biệt rõ ràng giữa mã và dữ liệu.

    Nếu kẻ tấn công cung cấp một chuỗi độc hại như trong các ví dụ trên, chẳng hạn như cung cấp John 'hoặc 1 = 1 cho tên người dùng, thì câu lệnh chuẩn bị sẽ đánh giá đây là một chuỗi ký tự . Nó sẽ tìm kiếm người dùng có tên John 'hoặc 1 = 1 (và không thành công, vì không có người dùng đó tồn tại) thay vì đánh giá câu lệnh này là mã.

    Các câu lệnh chuẩn bị sẵn có trong tất cả các ngôn ngữ lập trình. Đây là một ví dụ trong Java. Để an toàn, OWASP khuyên bạn nên xác thực tham số đầu vào đề phòng.

    // Định nghĩa riêng của biến đầu vào
    String custname = request.getParameter ("customerName");
    // Định nghĩa riêng về câu lệnh SQL
    String query = "SELECT account_balance FROM user_data WHERE user_name =?";
    // Lệnh PreparedStatement kết hợp an toàn các đầu vào và cú pháp SQL
    PreparedStatement pstmt = connect.prepareStatement (truy vấn);
    pstmt.setString (1, custname);
    ResultSet results = pstmt.executeQuery ();

    Defense Tùy chọn 2: Thủ tục được lưu trữ

    Các thủ tục được lưu trữ tương tự như các câu lệnh đã chuẩn bị, chỉ có mã SQL cho thủ tục được lưu trữ được xác định và lưu trữ trong cơ sở dữ liệu chứ không phải trong mã của người dùng. Trong hầu hết các trường hợp, các thủ tục được lưu trữ có thể an toàn như các câu lệnh đã soạn sẵn, vì vậy bạn có thể quyết định cái nào phù hợp hơn với các quy trình phát triển của mình.

    Có hai trường hợp mà các thủ tục được lưu trữ không an toàn:

    • Thủ tục được lưu trữ bao gồm tạo SQL động – điều này thường không được thực hiện trong các thủ tục được lưu trữ, nhưng nó có thể được thực hiện, vì vậy bạn phải tránh nó khi tạo các thủ tục được lưu trữ. Nếu không, hãy đảm bảo bạn xác thực tất cả các đầu vào.
    • Đặc quyền của chủ sở hữu cơ sở dữ liệu – trong một số thiết lập cơ sở dữ liệu, quản trị viên cấp quyền cho chủ sở hữu cơ sở dữ liệu để cho phép chạy các thủ tục đã lưu trữ. Điều này có nghĩa là nếu kẻ tấn công xâm phạm máy chủ, chúng có toàn quyền đối với cơ sở dữ liệu. Tránh điều này bằng cách tạo một vai trò tùy chỉnh chỉ cho phép các thủ tục lưu trữ ở mức độ truy cập mà chúng cần.

    Đây là ví dụ về một thủ tục được lưu trữ trong Java (Java gọi nó là CallableStatement < / mã>). Chúng tôi giả định rằng thủ tục được lưu trữ sp_getAccountBalancer thực hiện cùng một logic như câu lệnh đã chuẩn bị trong tùy chọn 1 ở trên.

    // Định nghĩa riêng về đầu vào của người dùng
    String custname = request.getParameter ("customerName");
    // Thực thi quy trình đã lưu trữ sp_getAccountBalancer
    thử {
    CallableStatement cs = connection.prepareCall ("{call
    sp_getAccountBalance (?)} ");
    cs.setString (1, custname);
    ResultSet results = cs.executeQuery ();
    // xử lý tập hợp kết quả
    } catch (SQLException se) {< br /> // ghi nhật ký và xử lý lỗi
    }

    Defense Option 3: Allow-list Input Validation

    Đây là một điểm mạnh khác biện pháp có thể bảo vệ chống lại SQL injection. Ý tưởng về xác thực danh sách cho phép là thông tin đầu vào của người dùng được xác thực dựa trên danh sách kín các giá trị pháp lý đã biết.

    Ví dụ: nếu thông tin đầu vào của người dùng được sử dụng để chọn bảng cơ sở dữ liệu, bạn có thể sử dụng mã như thế này để đảm bảo rằng nó chỉ có thể khớp với một trong một số tên bảng đã biết:

    String tableName;
    switch (PARAM):
    case "Value1": tableName = "fooTable ";
    break;
    case" Value2 ": tableName =" barTable ";
    break;
    ...
    default: ném InputValidationException mới (" giá trị không mong muốn < br /> Được cung cấp "+" cho tên bảng ");

    Một cách an toàn khác để xử lý dữ liệu nhập của người dùng là chuyển chúng sang dạng không phải chuỗi. Ví dụ: nếu đầu vào của người dùng xác định xem truy vấn nên được sắp xếp theo thứ tự tăng dần hay giảm dần, thì đầu vào có thể được chuyển đổi thành boolean. Và sau đó giá trị boolean này được sử dụng để xác định thứ tự sắp xếp:

    public String someMethod (boolean sortOrder) {
    String SQLquery = "some SQL ... order by Salary" + (sortOrder? "ASC":
    "DESC"); `
    ...

    Phòng thủ Tùy chọn 4: Thoát tất cả đầu vào do người dùng cung cấp

    Thoát nghĩa là thêm một ký tự thoát hướng dẫn mã bỏ qua một số kiểm soát các ký tự, đánh giá chúng dưới dạng văn bản chứ không phải dưới dạng mã.

    Tùy chọn này kém an toàn nhất trong bốn tùy chọn và chỉ nên được sử dụng như một phương sách cuối cùng. Điều này là do việc thoát đầu vào của người dùng chỉ hiệu quả nếu mã thoát khỏi tất cả các khả năng của các ký tự điều khiển và những kẻ tấn công nghĩ ra nhiều cách sáng tạo để đưa chúng vào. Do đó, OWASP không khuyến nghị phương pháp này và khuyên bạn nên sử dụng các tùy chọn 1 hoặc 2 ở trên.

    Ví dụ: trong MySQL có hai chế độ thoát - ANSI_QUOTES SQL < / code> mode và MySQL mode:

    • ở chế độ ANSI_QUOTES, để thoát khỏi các ký tự điều khiển, hãy mã hóa tất cả các ký tự '(một lần đánh dấu) bằng ”(hai dấu tích)
    • Trong chế độ MySQL, hãy thoát các ký tự sau:
      • \ 0 [số 0, không phải chữ O]
      • \ b
      • \ t
      • \ n
      • \ r
      • \ Z
      • \ ”
      • \%
      • < li> \ '

      • \\ [thoát một ký tự gạch chéo]
      • \ _
      • Thay thế tất cả các ký tự không phải chữ và số khác bằng các giá trị ASCII
      • Thay thế các số nhỏ hơn 256 bằng \ c trong đó 'c' là số gốc

    OWASP cung cấp nguồn mở, miễn phí API bảo mật doanh nghiệp (ESAPI) , có thể giúp bạn triển khai thoát trong mã cơ sở dữ liệu kế thừa. Nó cung cấp codec cho các cơ sở dữ liệu phổ biến, các cơ sở dữ liệu này đã thoát cho tất cả các mẫu điều khiển không an toàn.

    ESAPI hiện hỗ trợ Oracle và MySQL, đồng thời sẽ sớm hỗ trợ bộ mã hóa cho SQL Server và PostgreSQL.

    Ngăn chặn tấn công SQL Injection với Bright

    Kiểm tra bảo mật ứng dụng động Bright (DAST) giúp tự động hóa việc phát hiện và khắc phục nhiều lỗ hổng bảo mật bao gồm SQLi, trong giai đoạn đầu của quá trình phát triển, trên các ứng dụng web và API.

    Bằng cách chuyển các lần quét DAST sang trái và tích hợp chúng vào SDLC, các nhà phát triển và chuyên gia bảo mật ứng dụng có thể phát hiện sớm các lỗ hổng bảo mật và khắc phục chúng trước khi chúng xuất hiện trong phiên bản sản xuất. Bright hoàn thành quá trình quét trong vài phút và không có kết quả dương tính giả nào, bằng cách tự động xác nhận mọi lỗ hổng. Điều này cho phép các nhà phát triển áp dụng giải pháp và sử dụng nó trong suốt vòng đời phát triển.

    Quét bất kỳ ứng dụng web nào hoặc các API REST, SOAP và GraphQL để ngăn các lỗ hổng chèn SQL - dùng thử miễn phí < strong>.

    Xem Hướng dẫn bổ sung của chúng tôi về các chủ đề chính về bảo mật dữ liệu

    Cùng với các đối tác nội dung, chúng tôi đã biên soạn các hướng dẫn chuyên sâu về một số chủ đề khác cũng có thể hữu ích khi bạn khám phá thế giới của bảo mật dữ liệu

    Được ủy quyền bởi Imperva

    Tìm hiểu về các quy định về quyền riêng tư của dữ liệu và các quy trình quản trị có thể giúp đạt được sự tuân thủ.

    Được Cato ủy quyền

    Tìm hiểu về mô hình bảo mật Zero Trust và các giải pháp truy cập mạng zero Trust (ZTNA) được sử dụng để triển khai mô hình này.

    Được ủy quyền bởi Exabeam

    Tìm hiểu về các giải pháp bảo vệ chống mất dữ liệu (DLP) có thể ngăn dữ liệu nhạy cảm khỏi bị mất, trộm và rò rỉ.


Xem thêm những thông tin liên quan đến chủ đề làm thế nào để thực hiện một cuộc tấn công tiêm sql

SQL Injection - Lab #3 SQLi UNION attack determining the number of columns returned by the query

  • Tác giả: Rana Khalil
  • Ngày đăng: 2021-03-21
  • Đánh giá: 4 ⭐ ( 6486 lượt đánh giá )
  • Khớp với kết quả tìm kiếm: In this video, we cover Lab 3 in the SQL injection track of the Web Security Academy. This lab contains a SQL injection vulnerability in the product filter category field. This vulnerability can be exploited using a UNION attack to retrieve data from other tables. To solve the lab, we perform a SQL injection attack that determines the number of columns that are being returned by the query.This is the first step of a SQL injection UNION attack. We'll use this technique in subsequent labs to construct the full attack.

    ▬ ✨ Support Me ✨ ▬▬▬▬▬▬▬▬▬▬
    Buy my course: https://academy.ranakhalil.com/p/web-security-academy-video-series

    ▬ Contents of this video ▬▬▬▬▬▬▬▬▬▬
    00:00​​​​ - Introduction
    01:36​​​ - Understand the exercise and make notes about what is required to solve it
    13:14​​​ - Exploit the lab manually
    20:46​​​ - Script the exploit
    33:27 - Summary
    34:00​​​ - Thank You

    ▬ Links ▬▬▬▬▬▬▬▬▬▬
    SQL injection Lab 2 video (previous video): https://www.youtube.com/watch?v=fMPvCyD2v4w
    SQL Injection | Complete Guide (theory video): https://www.youtube.com/watch?v=1nJgupaUPEQ
    Python script: https://github.com/rkhal101/Web-Security-Academy-Series/blob/main/sql-injection/lab-03/sqli-lab-03.py
    Notes.txt document: https://github.com/rkhal101/Web-Security-Academy-Series/blob/main/sql-injection/lab-03/notes.txt
    Web Security Academy: https://portswigger.net/web-security​
    Rana's Twitter account: https://twitter.com/rana__khalil

Hướng dẫn test SQL Injection (Ví dụ và cách phòng ngừa các cuộc tấn công SQL Injection)

  • Tác giả: itzone.com.vn
  • Đánh giá: 4 ⭐ ( 6144 lượt đánh giá )
  • Khớp với kết quả tìm kiếm: The ITZone platform Vietnam is the community for anyone interested in news, training seminars, presentations etc in the IT industry

SQL Injection: Quá trình tấn công, hậu quả và cách phòng chống

  • Tác giả: blog.kdata.vn
  • Đánh giá: 5 ⭐ ( 8564 lượt đánh giá )
  • Khớp với kết quả tìm kiếm: SQL Injection là kiểu tấn công mạng phổ biến mà bạn cần biết: khái niệm, quá trình tấn công, hậu quả và cách phòng chống bảo vệ website

Tấn công Man-in-the-Middle (MitM) là gì và cách phòng tránh!

  • Tác giả: www.bitdefender.vn
  • Đánh giá: 5 ⭐ ( 2245 lượt đánh giá )
  • Khớp với kết quả tìm kiếm: Một cuộc tấn công MitM thường là một cuộc tấn công linh hoạt, xâm chiếm và bí mật. Tấn công man-in-the-middle xảy ra khi ai đó ở giữa hai máy tính (máy tính xách tay và máy chủ từ xa) và có khả năng chặn lưu lượng truy cập. Kẻ đó có thể nghe trộm hoặc thậm chí chặn liên lạc giữa hai máy và đánh cắp thông tin nhạy cảm. Các cuộc tấn công man-in-the-middle là một vấn đề bảo mật nghiêm trọng.

Kiến thức về Tấn Công Mạng từ A-Z

  • Tác giả: vietnix.vn
  • Đánh giá: 3 ⭐ ( 1347 lượt đánh giá )
  • Khớp với kết quả tìm kiếm: Tấn công mạng là gì? Các hình thức tấn công mạng phổ biến hiện nay và lý do tại sao bạn phải cần ngăn chăn việc tấn công mạng xảy ra.

Một số biện pháp kỹ thuật phòng chống tấn công từ chối dịch vụ

  • Tác giả: www.kontum.gov.vn
  • Đánh giá: 3 ⭐ ( 2351 lượt đánh giá )
  • Khớp với kết quả tìm kiếm: Cổng thông tin điện tử tỉnh Kon Tum, tỉnh Kon Tum, Kon Tum, Ủy ban nhân dân tỉnh Kon Tum, chính quyền và nhân dân tỉnh Kon Tum

Hướng dẫn test SQL Injection (Ví dụ và cách phòng ngừa các cuộc tấn công SQL Injection)

  • Tác giả: viblo.asia
  • Đánh giá: 3 ⭐ ( 8661 lượt đánh giá )
  • Khớp với kết quả tìm kiếm: Ở bài post này, mình xin giới thiệu với các bạn các ví dụ về SQL Injection và các cách phòng tránh các cuộc tấn công SQL Injection khi test Web.

Xem thêm các bài viết khác thuộc chuyên mục: Kiến thức lập trình

By ads_php