Làm thế nào để gỡ lỗi một ứng dụng web PHP một cách an toàn mà không tiết lộ bí mật cho các đối thủ cạnh tranh?

Gần đây tôi đã thực hiện một chương trình. Tôi quên xóa 2 dòng mã. Sai lầm đó khiến tôi mất 800 đô la mỗi ngày.

Tôi đã lập trình với PHP. Nếu khách truy cập sử dụng proxy, nó sẽ chuyển hướng đến một nơi khác. Sử dụng trình gỡ lỗi là không thể vì một số mã có chứa ioncube. Bởi vì chương trình chỉ đơn giản là chuyển hướng đến một nơi khác bất kể là gì, thật khó để xem phần nào của mã được thực thi.

Vì vậy, tôi đặt một loạt các thông tin gỡ lỗi ở khắp mọi nơi. Tôi nghĩ rằng tôi sẽ xóa chúng sau.

Tất nhiên, cách gỡ lỗi tự nhiên nhất là đưa thông tin gỡ lỗi vào một tệp. Vấn đề là tôi thường sử dụng proxy. Vì vậy, sau khi tôi thay đổi chương trình, tôi thường phải tải xuống tệp văn bản với filezilla. Thường thì tệp văn bản không hiển thị những gì tôi nghĩ nó sẽ hiển thị. Cuối cùng tôi quyết định chỉ hiển thị lỗi trên web.

Tôi xem xét có chế độ gỡ lỗi. Tuy nhiên, tôi sợ tôi sẽ quên xóa thông tin gỡ lỗi.

Tôi đã xem xét việc có chế độ gỡ lỗi nếu người dùng thực hiện? Debuggingmode = 1 chẳng hạn. Tuy nhiên, tôi đã hoang tưởng rằng bằng cách nào đó đối thủ của tôi có thể đoán được từ khóa bí mật.

Tôi đã xóa hầu hết các thông tin gỡ lỗi. Tôi quên xóa một và cái đó chỉ hiển thị nếu người dùng sử dụng proxy từ đúng quốc gia. Hóa ra tôi không có proxy từ đúng quốc gia và không nhận ra điều đó. Sau khi chương trình hoạt động được 24 giờ, tôi đã tải nó lên miền chính của mình.

Đối thủ của tôi, sử dụng proxy, xem mã gỡ lỗi. Anh ta sao chép ý tưởng và đó là cách tôi mất $ 800 mỗi ngày.

Nhìn lại, tôi thực sự có một thời gian khó khăn để xem tôi đã sai ở đâu. Tôi đã siêu cẩn thận. Vậy mà nó đã xảy ra.

Làm thế nào để gỡ lỗi một ứng dụng web PHP một cách an toàn mà không tiết lộ bí mật cho các đối thủ cạnh tranh?

Tôi thực sự có một thời gian khó khăn để xem tôi đã sai ở đâu

Sai lầm chính là bạn đã phát minh lại bánh xe. Thay vì sử dụng mecanism mặc định để đăng nhập, bạn đã phát minh ra chính bạn , nơi hiển thị thông tin trong trang. Khung ghi nhật ký thay vì lưu trữ nhật ký trong tệp nhật ký, cho phép bạn tham khảo các nhật ký đó sau bằng cách SSH tới máy chủ.

Đối với các lỗi, việc tạo mã không có lỗi ngụ ý sử dụng các kỹ thuật cụ thể như bằng chứng chính thức . Với khả năng mở rộng của chúng, những kỹ thuật này phù hợp cho các ứng dụng quan trọng trong cuộc sống như các ứng dụng kiểm soát lưu lượng máy bay hoặc tàu con thoi vũ trụ, nhưng là một quá mức cần thiết cho gần như mọi ứng dụng kinh doanh.

■ Xem Họ viết đúng nội dung trên tạp chí Fast Company.
_{Bài viết mô tả phương pháp được sử dụng tại NASA, cũng như chi phí sản xuất phần mềm theo cách này.}

■ Xem Bằng chứng cơ giới hóa (Mackenzie 2004).
_{Cuốn sách tóm tắt lịch sử chứng minh phần mềm tự động, giải thích những ưu và nhược điểm của bằng chứng đó, cũng như lý do nó không được các doanh nghiệp sử dụng để viết phần mềm đáng tin cậy.}

Điều này đang được nói, có một loạt các kỹ thuật được sử dụng cho các ứng dụng kinh doanh để đảm bảo chất lượng phần mềm. Những người bao gồm nhưng không giới hạn ở:

• Đánh giá mã không chính thức,
• Kiểm tra mã chính thức,
• Kiểm tra,
• Bàn làm việc cá nhân kiểm tra mã,
• Vân vân.

■ Xem Mã hoàn chỉnh (McConnell 2004), Năng suất lập trình (Jones 1986a), Hiệu quả loại bỏ lỗi phần mềm (Jones 1996) và những gì chúng tôi đã học về khuyết tật chiến đấu (Shull et al. 2002).

Ngoài ra, đừng quên tích hợp liên tục và giao hàng liên tục. Nó giúp tự động đưa ứng dụng trở lại trong phiên bản đang hoạt động khi phiên bản sửa đổi dường như có một vấn đề bị bỏ sót trong quá trình đánh giá mã và kiểm tra đơn vị, nhưng bị bắt khi ứng dụng được triển khai.

■ Xem Bí mật để triển khai liên tục an toàn (video)
_{Nó giải thích những kỹ thuật nào đã được thiết lập tại Google để ngăn chặn các lỗi không thể tìm thấy trước khi triển khai quá lâu trong sản xuất. Nó cũng mô tả pdiffvà làm thế nào nó được sử dụng để bắt lỗi, bao gồm cả những lỗi không liên quan đến lớp trình bày.}

Bạn không bao giờ nên gỡ lỗi trong sản xuất.

Bạn phải luôn có một môi trường thử nghiệm giống hệt với môi trường sản xuất và gỡ lỗi ở đó.

Khi bạn cần thay đổi mã trong môi trường thử nghiệm (như để thêm các câu lệnh gỡ lỗi), bạn nên đảm bảo rằng chúng không đi vào sản xuất.

Một thiết lập chuyên nghiệp thường trông như thế này:

Production
   ^
Staging
   ^
Development

Các phiên bản "Sản xuất", "Phân đoạn" và "Phát triển" trong ứng dụng của bạn phải giống hệt nhau nhất có thể để một lỗi xảy ra trong "Sản xuất" có thể được sao chép trong "Phân đoạn" và "Phát triển", nhưng vẫn được tách biệt hoàn toàn khỏi lẫn nhau để bất cứ điều gì xảy ra trong một trong các trường hợp không ảnh hưởng đến những người khác.

Khi bạn cần phân tích một vấn đề, bạn làm như vậy trong "Phát triển". Xung quanh với các câu lệnh gỡ lỗi và thử nghiệm tất cả những gì bạn muốn. Khi bạn tìm thấy giải pháp, bạn áp dụng bản sửa lỗi đó cho cơ sở mã không thay đổi trong "Phân đoạn" và xác minh rằng bản sửa lỗi hoạt động. Sau đó, bạn thúc đẩy sửa chữa để "Sản xuất".

Một hệ thống quản lý xây dựng và kiểm soát phiên bản phù hợp có thể giúp bạn điều đó.

Điều này hiếm khi được thực hiện vì nỗ lực không đáng. Ngay cả khi bạn mất 800 đô la mỗi ngày, nỗ lực chứng minh một chương trình chính xác nhanh chóng trở nên lớn hơn thế, điều đó ngụ ý rằng không có trường hợp kinh doanh nào để thực hiện nó.

Nếu chắc chắn là đáng giá (ví dụ như phần mềm Tàu con thoi hoặc điều khiển tên lửa), thì bạn thực hiện xác minh chính thức, kiểm tra toàn diện tất cả các đầu vào có thể, v.v. Cấp, nó cũng cực kỳ khó khăn cũng như chậm và tốn kém. Nhưng các dự án với ngân sách hàng tỷ đô la cũng có xu hướng có những người cực kỳ thông minh về họ. (Hoặc có thể họ chỉ quen với - các tiêu đề ngày nay dường như mâu thuẫn với quy tắc đó.)

Đôi khi bạn cần gỡ lỗi một hệ thống sống. Có, bạn nên có một bản sao phát triển hoặc dàn dựng. Nhưng luôn luôn có sự khác biệt. Điều này đặc biệt đúng nếu mã đang cạn kiệt trên phần cứng của khách hàng. Hoặc có khả năng, nhiều cài đặt khách hàng khác nhau.

Tôi đã sử dụng kỹ thuật & gỡ lỗi = 1 trong quá khứ. Tôi nghi ngờ hầu hết các nhà phát triển PHP có. Điều đó đã lật một công tắc trong mã cho phép gỡ lỗi dài hơn trong ứng dụng. Thông tin đó thường sẽ được chuyển vào một tệp nhật ký - nói chung là nhật ký apache (sử dụng error_log ()). Nhưng, bạn cũng có thể xuất nó. Trình hồ sơ của chúng tôi, ví dụ, sẽ thu thập thông tin và sau đó xuất các điểm chuẩn khác nhau ở cuối trang. Bạn cũng có thể xuất thông tin gỡ lỗi dưới dạng nhận xét HTML hoặc trong phần tử ẩn chỉ có thể xem được nếu bạn xem nguồn trang.

Nếu trang web của bạn có 'người dùng, bạn chỉ có thể giới hạn gỡ lỗi cho một người dùng cụ thể. Bằng cách này nếu ai đó cố gắng kích hoạt gỡ lỗi, nó vẫn không hoạt động trừ khi họ đăng nhập với tư cách là người dùng đó.

Bây giờ, bạn đã đề cập rằng bạn đang sử dụng FileZilla để kết nối với máy chủ. Một nhà phát triển thực sự nên có quyền truy cập SSH vào máy chủ. Điều đó sẽ làm cho việc gỡ lỗi dễ dàng hơn nhiều cho bạn. Ví dụ: nếu bạn xuất các câu lệnh gỡ lỗi của mình sang nhật ký lỗi Apache, thì bạn có thể dễ dàng grep tệp đó cho địa chỉ IP của bạn và xem thông tin gỡ lỗi được tạo bởi yêu cầu trang cuối cùng của bạn.

Mọi người khác đã bao gồm trường hợp chung:

Xác nhận chính thức (/ Mã đã được chứng minh): Không khả thi đối với các chương trình trong thế giới thực, mặc dù có một hệ điều hành 4000 dòng, đã được chứng minh chính thức, Phải mất nhiều sinh viên Tiến sĩ CS Nga trong nhiều tháng (vui lòng nhận xét nếu nhớ tên của dự án này)

Kiểm tra CI << Kiểm tra tự động << Kiểm tra : đảm bảo bạn sử dụng công cụ bảo hiểm để kiểm tra các trường hợp kiểm tra của bạn có phạm vi bảo hiểm 100%.

Đối với trường hợp cụ thể của bạn về việc để lại mã gỡ lỗi trong sản xuất, tôi có 2 tùy chọn, cả hai đều yêu cầu mã nguồn phải được biên dịch lại như là một phần của việc triển khai sang môi trường mới (Phân đoạn / Thử nghiệm cuối).

1. Loại bỏ nó tại thời gian biên dịch. Gói mã gỡ lỗi trong các cấu trúc như C # và C #ifdef DEBUGđể kiểm tra mục tiêu xây dựng, (Gỡ lỗi hoặc Phát hành) và để tự động xóa chúng tại thời điểm biên dịch.

2. Đánh dấu nó vào thời gian triển khai. Đặt một bình luận gần mã không được chạy trong môi trường thực. Ví dụ: //TODO: Remove This Before DeploymentSau đó, khi nó được di chuyển (triển khai) sang Phân đoạn, trước khi biên dịch mã, hãy chạy mã thông qua một tập lệnh đơn giản để kiểm tra để đảm bảo không còn nhận xét Flag (ví dụ //TODO:) trong mã nguồn.

Tôi đề nghị trước đây nếu nó là dài hạn và bạn sẽ muốn nó một lần nữa (Ví dụ: chế độ ghi nhật ký dài dòng) và sau này nếu đó là một bản hack nhanh trong khi bạn gỡ lỗi (Ví dụ: các bản in khác nhau được phân tán qua mã của bạn)

Như những người khác đã nói trước tôi, rất nhiều bài kiểm tra (đơn vị và chức năng), nếu có thể được tự động hóa và với độ bao phủ mã tốt là chìa khóa để có một phần mềm không có lỗi.

Nếu tôi hiểu mô tả vấn đề của bạn đủ tốt, thông tin gỡ lỗi sẽ được hiển thị trên trang được phục vụ bởi máy chủ của bạn. Nếu đó là trường hợp, bạn nên xem xét đưa thông tin đó vào nhật ký thích hợp trên máy chủ của bạn. Bằng cách đó, nó không bao giờ được hiển thị cho người dùng cuối, ngay cả khi bạn triển khai phiên bản 'dài dòng' để sản xuất. Đây là một cái gì đó tốt để làm bất cứ dự án nào bạn đang làm trừ khi bạn có lý do rất chính đáng để làm khác.

Những gì người khác nói về gỡ lỗi trong sản xuất là đúng. Nhưng đôi khi tôi đã làm điều đó. Và tôi nghĩ có nhiều cách an toàn hơn để làm điều đó hơn là của bạn, mặc dù không có gì là không thể tin được.

Bản thân tôi không cần bảo mật cao như vậy, tôi chỉ không muốn người dùng thấy một loạt những lời nói tục tĩu trên màn hình của họ.

$debug = true;
$allowed_ips = array('192.168.0.220','173.46.89.255'); // limit to your own ip's. If your competitor knows them, though, he can spoof it! But if your stuff is not top secret, it's ok. 

if(!in_array($_SERVER['REMOTE_ADDR'],$allowed_ips) ) {
  $debug = false;
}

if($debug) {
  echo '<pre>' . print_r($some_variable) . '</pre>';
}

Bây giờ người dùng sẽ không thấy gỡ lỗi của bạn trừ khi họ thực sự muốn. Nếu $ 800 / ngày của bạn phụ thuộc vào việc giữ bí mật thông tin gỡ lỗi này, thì đừng sử dụng mã trên . Nhưng nếu thông tin không nhạy cảm, những điều trên sẽ tốt hơn nhiều so với việc phụ thuộc vào biến GET hoặc tiết lộ bí mật của bạn cho cả một quốc gia.

Ngoài ra, bạn có thể tạo một debuglớp hoặc chức năng sẽ kiểm tra xem việc in có được phép hay không dựa trên tiêu chí của bạn. Đó là những gì tôi làm.

Một cái gì đó như thế này:

class debug {
  public $on = false;
  public static function print($variable) {
    if($on) {
      echo '<pre>' . print_r($some_variable) . '</pre>';
    }
  }
}

debug::print($some_variable); // class checks if printing is allowed. If not, no printing occurs.

Đối với chương trình của tôi sẽ giúp tôi kiếm được 800 đô la / ngày (đang phát triển), tôi sử dụng apache mod auth để yêu cầu mật khẩu truy cập vào bất kỳ phần nào của trang web, cũng như hạn chế thông tin gỡ lỗi đối với một số IP nhất định. Câu hỏi của bạn làm cho tôi nghĩ rằng tôi nên xem xét bảo mật tốt hơn mặc dù.

Trên thực tế, tôi sẽ có hai xác nhận thêm ở đây. Một là &debug=1tham số trong yêu cầu. Bạn cũng có thể sử dụng một số biến phiên hoặc thiết lập cookie đặc biệt mà chỉ bạn mới có thể kích hoạt thông qua một cuộc gọi đến trang "bí mật" (tốt nhất là có xác thực).

Xác nhận thứ hai sẽ có trong tệp cấu hình, một mảng có dải IP và chỉ các cuộc gọi từ một IP trong mảng đó có thể kích hoạt chức năng gỡ lỗi. cái gì đó như

Trong cấu hình:

$debugAllowedIPs = array('127.0.0.1', '192.168.0.1', /* add more IPs here */);

Có phương pháp sau đây ở đâu đó nơi nó có thể được truy cập trên toàn cầu:

function getClientIp() {
    if (!empty($_SERVER['HTTP_CLIENT_IP']))  return $_SERVER['HTTP_CLIENT_IP'];
    if (!empty($_SERVER['HTTP_X_FORWARDED_FOR'])) return $_SERVER['HTTP_X_FORWARDED_FOR'];
    return $_SERVER['REMOTE_ADDR'];
}

Và trong mã của bạn gọi một cái gì đó như:

if (in_array(getClientIp(), $debugAllowedIPs)) { /* show debug info here */ }

Xin lưu ý rằng mã trong getClientIp()phương thức không an toàn vì giá trị $_SERVER['HTTP_X_FORWARDED_FOR']dễ bị giả mạo, tuy nhiên, nó sẽ phục vụ mục đích đưa ra quan điểm cho câu hỏi của bạn.