Các chức năng vệ sinh đầu vào PHP tốt nhất là gì?


161

Tôi đang cố gắng đưa ra một chức năng mà tôi có thể chuyển tất cả các chuỗi của mình thông qua để vệ sinh. Vì vậy, chuỗi đi ra khỏi nó sẽ an toàn cho việc chèn cơ sở dữ liệu. Nhưng có rất nhiều chức năng lọc ngoài đó tôi không chắc nên sử dụng / cần những chức năng nào.

Xin hãy giúp tôi điền vào chỗ trống:

function filterThis($string) {
    $string = mysql_real_escape_string($string);
    $string = htmlentities($string);
    etc...
    return $string;
}

4
để chèn, bạn chỉ cần vệ sinh chống lại việc tiêm SQL bằng mysql_real_escape_opes. Đó là khi bạn đang sử dụng dữ liệu CHỌN (trong đầu ra html hoặc trong công thức / hàm php) mà bạn nên áp dụng htmlentities
davidos Something

Xem stackoverflow.com/questions/60174/ cho một câu trả lời cụ thể để làm sạch để chèn cơ sở dữ liệu (nó đưa ra một ví dụ về PDO, mà những người khác đã đề cập dưới đây).
Pat

Câu trả lời:


433

Dừng lại!

Bạn đang mắc lỗi ở đây. Ồ, không, bạn đã chọn đúng các hàm PHP để làm cho dữ liệu của bạn an toàn hơn một chút. Tốt rồi. Lỗi của bạn là theo thứ tự các hoạt động , và cách sử dụng các chức năng này.

Điều quan trọng là phải hiểu sự khác biệt giữa vệ sinh và xác thực dữ liệu người dùng, thoát dữ liệu để lưu trữ và thoát dữ liệu để trình bày.

Vệ sinh và xác thực dữ liệu người dùng

Khi người dùng gửi dữ liệu, bạn cần đảm bảo rằng họ đã cung cấp thứ bạn mong đợi.

Vệ sinh và lọc

Ví dụ: nếu bạn mong đợi một số, hãy đảm bảo dữ liệu đã gửi là một số . Bạn cũng có thể truyền dữ liệu người dùng thành các loại khác. Mọi thứ được gửi ban đầu được xử lý như một chuỗi, do đó, việc buộc dữ liệu số đã biết thành số nguyên hoặc số float làm cho việc khử trùng nhanh và không gây đau đớn.

Còn các trường văn bản dạng tự do và textareas thì sao? Bạn cần đảm bảo rằng không có gì bất ngờ trong các lĩnh vực đó. Chủ yếu, bạn cần đảm bảo rằng các trường không có bất kỳ nội dung HTML nào không thực sự chứa HTML. Có hai cách bạn có thể đối phó với vấn đề này.

Trước tiên, bạn có thể thử thoát khỏi đầu vào HTML với htmlspecialchars. Bạn không nên sử dụng htmlentitiesđể vô hiệu hóa HTML, vì nó cũng sẽ thực hiện mã hóa các ký tự có dấu và các ký tự khác mà nó nghĩ cũng cần phải được mã hóa.

Thứ hai, bạn có thể thử xóa bất kỳ HTML nào có thể. strip_tagslà nhanh chóng và dễ dàng, nhưng cũng cẩu thả. Bộ lọc HTML thực hiện công việc kỹ lưỡng hơn nhiều về cả việc loại bỏ tất cả HTML và cũng cho phép một danh sách trắng các thẻ và thuộc tính chọn lọc thông qua.

Các phiên bản PHP hiện đại xuất xưởng với phần mở rộng bộ lọc , cung cấp một cách toàn diện để vệ sinh đầu vào của người dùng.

Thẩm định

Đảm bảo rằng dữ liệu đã gửi không có nội dung bất ngờ chỉ là một nửa của công việc. Bạn cũng cần thử và đảm bảo rằng dữ liệu được gửi có chứa các giá trị mà bạn thực sự có thể làm việc với.

Nếu bạn đang mong đợi một số trong khoảng từ 1 đến 10, bạn cần kiểm tra giá trị đó. Nếu bạn đang sử dụng một trong những đầu vào số ưa thích thời đại HTML5 mới với công cụ quay vòng và các bước, hãy đảm bảo rằng dữ liệu đã gửi phù hợp với bước này.

Nếu dữ liệu đó đến từ một menu thả xuống, hãy đảm bảo rằng giá trị được gửi là một giá trị xuất hiện trong menu.

Điều gì về đầu vào văn bản đáp ứng các nhu cầu khác? Ví dụ: đầu vào ngày phải được xác thực thông qua strtotimehoặc lớp DateTime . Ngày đã cho phải nằm trong khoảng bạn mong đợi. Địa chỉ email thì sao? Tiện ích mở rộng bộ lọc được đề cập trước đây có thể kiểm tra xem một địa chỉ có được định dạng tốt hay không, mặc dù tôi là người hâm mộ thư viện is_email .

Điều này cũng đúng với tất cả các điều khiển biểu mẫu khác. Có nút radio? Xác nhận đối với danh sách. Có hộp kiểm tra? Xác nhận đối với danh sách. Có một tập tin tải lên? Đảm bảo tệp thuộc loại dự kiến ​​và coi tên tệp như dữ liệu người dùng chưa được lọc.

Mỗi trình duyệt hiện đại đi kèm với một bộ đầy đủ các công cụ dành cho nhà phát triển được tích hợp ngay, điều này khiến cho mọi người thao túng biểu mẫu của bạn trở nên tầm thường. Mã của bạn nên cho rằng người dùng đã loại bỏ hoàn toàn tất cả các hạn chế phía máy khách đối với nội dung biểu mẫu !

Thoát dữ liệu để lưu trữ

Bây giờ bạn đã chắc chắn rằng dữ liệu của bạn ở định dạng mong đợi và chỉ chứa các giá trị dự kiến, bạn cần lo lắng về việc lưu giữ dữ liệu đó để lưu trữ.

Mỗi cơ chế lưu trữ dữ liệu duy nhất có một cách cụ thể để đảm bảo dữ liệu được thoát và mã hóa chính xác. Nếu bạn đang xây dựng SQL, thì cách được chấp nhận để truyền dữ liệu trong các truy vấn là thông qua các câu lệnh được chuẩn bị với trình giữ chỗ .

Một trong những cách tốt hơn để làm việc với hầu hết các cơ sở dữ liệu SQL trong PHP là phần mở rộng PDO . Nó tuân theo mô hình chung là chuẩn bị một câu lệnh , ràng buộc các biến với câu lệnh , sau đó gửi câu lệnh và biến đến máy chủ . Nếu bạn chưa từng làm việc với PDO trước đây thì đây là một hướng dẫn khá tốt về định hướng MySQL .

Một số cơ sở dữ liệu SQL có các phần mở rộng đặc biệt của riêng chúng trong PHP, bao gồm SQL Server , PostgreSQLSQLite 3 . Mỗi tiện ích mở rộng này đã chuẩn bị hỗ trợ câu lệnh hoạt động theo cùng kiểu chuẩn bị ràng buộc-thực thi như PDO. Đôi khi bạn có thể cần sử dụng các tiện ích mở rộng này thay vì PDO để hỗ trợ các tính năng hoặc hành vi không chuẩn.

MySQL cũng có các phần mở rộng PHP riêng. Hai trong số họ, trên thực tế. Bạn chỉ muốn sử dụng một cái gọi là mysqli . Phần mở rộng "mysql" cũ đã không còn được sử dụng và không an toàn hoặc lành mạnh để sử dụng trong thời kỳ hiện đại.

Cá nhân tôi không phải là fan hâm mộ của mysqli. Cách nó thực hiện ràng buộc thay đổi trên các báo cáo đã chuẩn bị là không linh hoạt và có thể là một nỗi đau để sử dụng. Khi nghi ngờ, sử dụng PDO thay thế.

Nếu bạn không sử dụng cơ sở dữ liệu SQL để lưu trữ dữ liệu của mình, hãy kiểm tra tài liệu cho giao diện cơ sở dữ liệu bạn đang sử dụng để xác định cách truyền dữ liệu qua dữ liệu một cách an toàn.

Khi có thể, hãy đảm bảo rằng cơ sở dữ liệu của bạn lưu trữ dữ liệu của bạn ở định dạng phù hợp. Lưu số trong các trường số. Lưu trữ ngày trong các trường ngày. Lưu trữ tiền trong trường thập phân, không phải trường dấu phẩy động. Xem lại tài liệu được cung cấp bởi cơ sở dữ liệu của bạn về cách lưu trữ đúng các loại dữ liệu khác nhau.

Thoát dữ liệu để trình bày

Mỗi khi bạn hiển thị dữ liệu cho người dùng, bạn phải đảm bảo rằng dữ liệu được thoát an toàn, trừ khi bạn biết rằng nó không nên được thoát.

Khi phát HTML, bạn hầu như luôn luôn chuyển bất kỳ dữ liệu nào ban đầu được cung cấp bởi người dùng htmlspecialchars. Trên thực tế, lần duy nhất bạn không nên làm điều này là khi bạn biết rằng người dùng đã cung cấp HTML và bạn biết rằng nó đã được khử trùng bằng cách sử dụng danh sách trắng.

Đôi khi bạn cần tạo một số Javascript bằng PHP. Javascript không có các quy tắc thoát giống như HTML! Một cách an toàn để cung cấp các giá trị do người dùng cung cấp cho Javascript thông qua PHP là thông qua json_encode.

Và hơn thế nữa

Có nhiều sắc thái hơn để xác nhận dữ liệu.

Ví dụ, mã hóa bộ ký tự có thể là một cái bẫy lớn . Ứng dụng của bạn nên tuân theo các thông lệ được nêu trong " UTF-8 suốt ". Có những cuộc tấn công giả định có thể xảy ra khi bạn coi dữ liệu chuỗi là tập ký tự sai.

Trước đó tôi đã đề cập đến các công cụ gỡ lỗi trình duyệt. Những công cụ này cũng có thể được sử dụng để thao tác dữ liệu cookie. Cookies nên được coi là đầu vào không đáng tin cậy của người dùng .

Xác thực và thoát dữ liệu chỉ là một khía cạnh của bảo mật ứng dụng web. Bạn nên tự biết về các phương pháp tấn công ứng dụng web để có thể xây dựng hệ thống phòng thủ chống lại chúng.


Và khi chỉ định nó, hãy chắc chắn rằng nó nằm trong danh sách các mã hóa được hỗ trợ.
Charles

3
Và hoàn toàn không sử dụng htmlentity, thay thế nó bằng htmlspecialchars nhằm mục đích thay thế <>, không phải mọi ký tự thành thực thể
Ý thức chung của bạn

6
Chỉ cần đảm bảo không gọi htmlspecialcharshai lần, bởi vì anh ấy nói về nó trong phần "Khi người dùng gửi phần dữ liệu" và trong phần "Khi hiển thị dữ liệu".
Savageman

2
Nâng cao. Câu trả lời hữu ích nhất mà tôi đã đọc từ nhiều câu hỏi và trả lời về SQL Injection.
akinuri

Hoàn toàn là một câu trả lời Chất lượng với nhiều giải thích và liên kết cho người dùng trong tương lai để khám phá nhiều tùy chọn hơn. Cũng nhận được một lần từ tôi ...
James Walker

32

Việc khử trùng hiệu quả nhất để ngăn chặn việc tiêm SQL là sử dụng tham số hóa PDO. Sử dụng các truy vấn được tham số hóa, truy vấn được tách ra khỏi dữ liệu, do đó loại bỏ mối đe dọa của việc tiêm SQL thứ nhất.

Về mặt loại bỏ HTML, strip_tagscó lẽ là ý tưởng tốt nhất để xóa HTML, vì nó sẽ chỉ xóa mọi thứ. htmlentitieslàm những gì nó nghe như, vì vậy mà làm việc, quá. Nếu bạn cần phân tích HTML nào sẽ cho phép (nghĩa là bạn muốn cho phép một số thẻ), bạn nên sử dụng một trình phân tích cú pháp hiện có trưởng thành như Bộ lọc HTML


2
Ôi trời, tôi đã viết lên bức tường văn bản khổng lồ đó chỉ vì tôi không thấy ai nhắc đến HTML Purifier, và ở đây bạn đã đánh bại tôi trong 40 phút. ;)
Charles

3
Bạn không nên chỉ tước HTML trên đầu ra? IMO bạn không bao giờ nên thay đổi dữ liệu đầu vào - bạn không bao giờ biết khi nào bạn cần nó
Joe Phillips

11

Nhập liệu cơ sở dữ liệu - Cách ngăn chặn SQL Injection

  1. Kiểm tra để đảm bảo dữ liệu của số nguyên kiểu, ví dụ, là hợp lệ bằng cách đảm bảo nó thực sự là một số nguyên
    • Trong trường hợp không có chuỗi, bạn cần đảm bảo rằng dữ liệu thực sự là đúng loại
    • Trong trường hợp chuỗi, bạn cần đảm bảo chuỗi được bao quanh bởi dấu ngoặc kép trong truy vấn (rõ ràng, nếu không, nó thậm chí sẽ không hoạt động)
  2. Nhập giá trị vào cơ sở dữ liệu trong khi tránh SQL tiêm (mysql_real_escape_opes hoặc truy vấn tham số)
  3. Khi truy xuất giá trị từ cơ sở dữ liệu, hãy chắc chắn tránh các cuộc tấn công Cross Site Scripting bằng cách đảm bảo HTML không thể được đưa vào trang (htmlspecialchars)

Bạn cần thoát khỏi đầu vào của người dùng trước khi chèn hoặc cập nhật nó vào cơ sở dữ liệu. Đây là một cách cũ hơn để làm điều đó. Bạn sẽ muốn sử dụng các truy vấn được tham số hóa ngay bây giờ (có thể từ lớp PDO).

$mysql['username'] = mysql_real_escape_string($clean['username']);
$sql = "SELECT * FROM userlist WHERE username = '{$mysql['username']}'";
$result = mysql_query($sql);

Đầu ra từ cơ sở dữ liệu - Cách ngăn XSS (Cross Site Scripting)

htmlspecialchars()Chỉ sử dụng khi xuất dữ liệu từ cơ sở dữ liệu. Điều tương tự cũng áp dụng cho Bộ lọc HTML. Thí dụ:

$html['username'] = htmlspecialchars($clean['username'])

Và cuối cùng ... những gì bạn yêu cầu

Tôi phải chỉ ra rằng nếu bạn sử dụng các đối tượng PDO với các truy vấn được tham số hóa (cách thích hợp để làm điều đó) thì thực sự không có cách nào dễ dàng để đạt được điều này một cách dễ dàng. Nhưng nếu bạn sử dụng cách 'mysql cũ thì đây là thứ bạn cần.

function filterThis($string) {
    return mysql_real_escape_string($string);
}

5

5 xu của tôi.

Không ai ở đây hiểu cách mysql_real_escape_stringlàm việc. Chức năng này không lọc hoặc "vệ sinh" bất cứ thứ gì.
Vì vậy, bạn không thể sử dụng chức năng này như một số bộ lọc phổ quát sẽ cứu bạn khỏi tiêm.
Bạn chỉ có thể sử dụng nó khi bạn hiểu cách thức hoạt động và nơi áp dụng.

Tôi có câu trả lời cho câu hỏi tương tự tôi đã viết: Trong PHP khi gửi chuỗi vào cơ sở dữ liệu, tôi nên chăm sóc các ký tự không hợp lệ bằng cách sử dụng htmlspecialchars () hoặc sử dụng biểu thức chính quy?
Xin vui lòng bấm vào để giải thích đầy đủ cho an toàn bên cơ sở dữ liệu.

Đối với các htmlentity - Charles nói đúng với bạn để tách các chức năng này.
Chỉ cần tưởng tượng bạn sẽ chèn một dữ liệu, được tạo bởi quản trị viên, người được phép đăng HTML. chức năng của bạn sẽ làm hỏng nó.

Mặc dù tôi khuyên bạn nên chống lại htmlentity. Chức năng này đã trở nên lỗi thời từ lâu. Nếu bạn muốn thay thế chỉ <, >"nhân vật trong lợi ích của an toàn HTML - sử dụng chức năng được phát triển cố tình cho mục đích đó - một htmlspecialchars () một.


1
mysql_real_escape_stringthoát các ký tự cần thiết bên trong một chuỗi. Nó không hoàn toàn lọc hoặc vệ sinh, nhưng kèm theo một chuỗi trong dấu ngoặc kép là không (và mọi người đều làm như vậy, tôi gần như không bao giờ thấy câu hỏi nào về nó). Vì vậy, không có gì được vệ sinh khi chúng ta viết SQL? Dĩ nhiên là không. Điều ngăn cản việc tiêm SQL là việc sử dụng mysql_real_escape_string. Ngoài ra các trích dẫn kèm theo, nhưng mọi người đều làm điều đó và nếu bạn kiểm tra những gì bạn làm, bạn sẽ bị lỗi cú pháp SQL với thiếu sót này. Phần nguy hiểm thực sự được xử lý với mysql_real_escape_string.
Savageman

@Savageman xin lỗi bạn, bạn hiểu không phải là một điều. Bạn không hiểu cách thức hoạt động của mysql_real_escape_opes. Những "nhân vật cần thiết" là dấu ngoặc kép. Không phải chức năng này cũng không trích dẫn một mình vệ sinh bất cứ điều gì. 2 điều này chỉ hoạt động với nhau . Làm cho chuỗi truy vấn chỉ đúng về mặt cú pháp, không "an toàn khi tiêm". Và lỗi cú pháp nào tôi sẽ nhận được chỉ WHERE id = 1? ;)
Ý thức chung của bạn

Thử WHERE my_field = two words (không có dấu ngoặc kép) để nhận lỗi cú pháp. Ví dụ của bạn rất tệ bởi vì nó không cần trích dẫn cũng không thoát, chỉ cần kiểm tra số. Ngoài ra tôi đã không nói rằng các trích dẫn là vô ích. Tôi đã nói tất cả mọi người sử dụng chúng vì vậy đây không phải là nguồn gốc của các vấn đề liên quan đến việc tiêm SQL.
Savageman

1
@Savageman vì vậy, tôi đã nói: Bạn chỉ có thể sử dụng nó khi bạn hiểu cách thức hoạt động và nơi áp dụng. Bạn vừa thừa nhận rằng mysql_real_escape_opes không được áp dụng ở mọi nơi. Đối với everyone use thembạn có thể kiểm tra mã ở đây trên SO. Nhiều người không sử dụng dấu ngoặc kép với số. Đi hình. Xin vui lòng, hãy nhớ rằng tôi không thảo luận ở đây những gì bạn đã nói và khi bạn không nói. Tôi chỉ giải thích các quy tắc an toàn cơ sở dữ liệu cơ bản. Bạn nên học tốt hơn thay vì tranh luận trống rỗng. Không ai đề cập đến trích dẫn hoặc truyền ở đây nhưng m_r_e_s chỉ như thể đó là phép thuật. Những gì tôi đang nói về
Ý thức chung của bạn

1
một lên, cũng như @Charles. Là một người mới, tương tác cơ sở dữ liệu ... làm cho mọi thứ an toàn cho đầu vào và hiển thị, các ký tự đặc biệt, các vấn đề tiêm, đã là một đường cong học tập rất dốc. Đọc bài đăng của bạn và của anh ấy (cũng như các câu trả lời PHP khác của bạn cho các câu hỏi khác, đã giúp tôi rất nhiều. Tx cho tất cả các đầu vào của bạn.
James Walker

2

Để chèn cơ sở dữ liệu, tất cả những gì bạn cần là mysql_real_escape_string(hoặc sử dụng các truy vấn được tham số hóa). Bạn thường không muốn thay đổi dữ liệu trước khi lưu nó, đó là điều sẽ xảy ra nếu bạn sử dụng htmlentities. Điều đó sẽ dẫn đến một mớ hỗn độn bị cắt xén sau này khi bạn chạy htmlentitieslại để hiển thị nó ở đâu đó trên trang web.

Sử dụng htmlentities khi bạn đang hiển thị dữ liệu trên một trang web ở đâu đó.

Một phần nào đó có liên quan, nếu bạn đang gửi dữ liệu đã gửi ở đâu đó trong email, chẳng hạn như với biểu mẫu liên hệ, hãy chắc chắn loại bỏ dòng mới khỏi bất kỳ dữ liệu nào sẽ được sử dụng trong tiêu đề (như Từ: tên và địa chỉ email, phụ, v.v. )

$input = preg_replace('/\s+/', ' ', $input);

Nếu bạn không làm điều này chỉ là vấn đề thời gian trước khi các bot spam tìm thấy biểu mẫu của bạn và lạm dụng nó, tôi đã học được cách khó khăn.



2

Nó phụ thuộc vào loại dữ liệu bạn đang sử dụng. Cách tốt nhất để sử dụng sẽ làmysqli_real_escape_string , nhưng, ví dụ, bạn biết sẽ không có nội dung HTML, sử dụng dải phân cách sẽ tăng thêm bảo mật.

Bạn cũng có thể xóa các ký tự mà bạn biết không nên cho phép.


1

Tôi luôn khuyên bạn nên sử dụng gói xác nhận nhỏ như GUMP: https://github.com/Wixel/GUMP

Xây dựng tất cả các chức năng cơ bản của bạn trong một thư viện như thế này và gần như không thể quên vệ sinh. "mysql_real_escape_opes" không phải là giải pháp thay thế tốt nhất để lọc tốt (như "Ý thức chung của bạn" đã giải thích) - và nếu bạn quên chỉ sử dụng một lần, toàn bộ hệ thống của bạn sẽ bị tấn công thông qua việc tiêm và các tấn công khó chịu khác.


1

Đối với tất cả những người ở đây nói về và dựa vào mysql_real_escape_opes, bạn cần lưu ý rằng chức năng đó không được dùng nữa trên PHP5 và không còn tồn tại trên PHP7.

IMHO cách tốt nhất để thực hiện nhiệm vụ này là sử dụng các truy vấn được tham số hóa thông qua việc sử dụng PDO để tương tác với cơ sở dữ liệu. Kiểm tra điều này: https://phpdelusions.net/pdo_examples/select

Luôn sử dụng các bộ lọc để xử lý đầu vào của người dùng. Xem http://php.net/manual/es/feft.filter-input.php


Điều này không thực sự trả lời câu hỏi. Xem xét sửa đổi câu trả lời của bạn để bao gồm một giải pháp.
kris

Hy vọng bạn thích nó!
Kuntur

Tôi làm. Câu trả lời tốt đẹp!
kris

Tôi đề nghị lưu ý rằng trong PHP 7 mysqli_real_escape_string()có sẵn.
Chris

Xin chào Chris, các giải pháp được trình bày ở đây đã tham chiếu đến mysql_real_escape_opes, tôi nhận thấy ai đã đọc từ bây giờ rằng nó không còn tồn tại trên PHP7 và đề xuất một giải pháp thay thế bằng PDO (và các bộ lọc) chứ không phải mysqli. Vui lòng thêm một ghi chú giải thích một giải pháp bằng cách sử dụng những gì bạn đề xuất. Trân trọng
Kuntur

0

Bạn sử dụng mysql_real_escape_opes () trong mã tương tự như sau.

$query = sprintf("SELECT * FROM users WHERE user='%s' AND password='%s'",
  mysql_real_escape_string($user),
  mysql_real_escape_string($password)
);

Như tài liệu nói, mục đích của nó là thoát các ký tự đặc biệt trong chuỗi được truyền dưới dạng đối số, có tính đến bộ ký tự hiện tại của kết nối để an toàn khi đặt nó vào mysql_query () . Tài liệu cũng cho biết thêm:

Nếu dữ liệu nhị phân được chèn, chức năng này phải được sử dụng.

htmlentities () được sử dụng để chuyển đổi một số ký tự trong các thực thể, khi bạn xuất một chuỗi trong nội dung HTML.


0

Đây là một trong những cách tôi đang thực hành,

  1. Cấy csrf và mã thông báo cám dỗ muối cùng với yêu cầu được thực hiện bởi người dùng và xác thực tất cả chúng cùng với yêu cầu. Tham khảo tại đây
  2. đảm bảo không phụ thuộc quá nhiều vào cookie phía máy khách và đảm bảo thực hành sử dụng các phiên phía máy chủ
  3. khi có bất kỳ dữ liệu phân tích cú pháp nào, hãy đảm bảo chỉ chấp nhận kiểu dữ liệu và phương thức truyền (chẳng hạn như POST và GET)
  4. Đảm bảo sử dụng SSL cho ứng dụng / ứng dụng web của bạn
  5. Đảm bảo cũng tạo yêu cầu phiên cơ sở thời gian để hạn chế yêu cầu spam có chủ ý.
  6. Khi dữ liệu được phân tích cú pháp đến máy chủ, hãy đảm bảo xác thực yêu cầu phải được thực hiện trong cơ sở dữ liệu bạn muốn, chẳng hạn như json, html và vv ... và sau đó tiến hành
  7. thoát tất cả các thuộc tính bất hợp pháp khỏi đầu vào bằng cách sử dụng loại thoát ... chẳng hạn như realescORGring.
  8. sau đó xác minh định dạng duy nhất của loại dữ liệu bạn muốn từ người dùng.
    Ví dụ:
    - Email: kiểm tra xem đầu vào có ở định dạng email hợp lệ
    - văn bản / chuỗi: Chỉ kiểm tra đầu vào chỉ có định dạng văn bản (chuỗi)
    - số: chỉ cho phép kiểm tra định dạng số.
    - v.v. Pelase tham khảo thư viện xác thực đầu vào php từ cổng thông tin php
    - Sau khi xác thực, vui lòng tiếp tục sử dụng câu lệnh SQL / PDO đã chuẩn bị.
    - Sau khi hoàn tất, hãy đảm bảo thoát và chấm dứt kết nối
    - Đừng quên xóa giá trị đầu ra sau khi thực hiện xong.

Đó là tất cả những gì tôi tin là đủ cho giây cơ bản. Nó sẽ ngăn chặn tất cả các cuộc tấn công lớn từ tin tặc.

Để bảo mật phía máy chủ, bạn có thể muốn cài đặt apache / htaccess của mình để hạn chế quyền truy cập và phòng ngừa robot và cả phòng ngừa định tuyến .. có rất nhiều việc phải làm đối với bảo mật phía máy chủ bên cạnh giây của hệ thống ở phía máy chủ.

Bạn có thể tìm hiểu và nhận một bản sao của giây từ cấp độ apache sec htaccess (các rpactices phổ biến)


0
function sanitize($string,$dbmin,$dbmax){
$string = preg_replace('#[^a-z0-9]#i', '', $string); //useful for strict cleanse, alphanumeric here
$string = mysqli_real_escape_string($con, $string); //get ready for db
if(strlen($string) > $dbmax || strlen($string) < $dbmin){
    echo "reject_this"; exit();
    }
return $string;
}

0

cái này thì sao

$string = htmlspecialchars(strip_tags($_POST['example']));

hoặc cái này

$string = htmlentities($_POST['example'], ENT_QUOTES, 'UTF-8');
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.