Điểm:1

Sửa lỗi duyệt thư mục cho cấu hình nginx

lá cờ in

Tôi phát hiện ra rằng trang web của mình có vấn đề này và tôi không thể khắc phục vấn đề này. Tôi đã thử một số cách như kiểm tra xem các vị trí tiền tố gốc cho chỉ thị bí danh Nginx có kết thúc bằng dấu tách thư mục hay không, nhưng cho đến nay vẫn chưa có may mắn. Bật Merge_slashes - là cài đặt mặc định. Tôi đã đọc về AppArmour hoặc SELinux. đó là phải đường để đi không? Tôi có Ubuntu 18. Nói cách khác, tôi có thể tải xuống tệp này http://example.com///etc/passwd và tôi muốn tránh điều này. Bất kỳ trợ giúp được đánh giá cao. Đây là cấu hình của tôi:

         người phục vụ {
  nghe 80;
  tên máy chủ
    .example.com;

 trả lại 301 https://example.com$request_uri;
}

người phục vụ {

tên máy chủ
  www.example.com;
    nghe 443 ssl http2;
    ssl_prefer_server_ciphers Bật;
    ssl_session_cache được chia sẻ:SSL:10m;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_dhparam /etc/ssl/certs/dhparam.pem;
    ssl_ciphers '......
    ssl_certificate /...crt;
    ssl_certificate_key /..key;

    trả lại 301 https://example.com$request_uri;
}
người phục vụ {

tên máy chủ
  ví dụ.com;
    nghe 443 ssl http2;
    ssl_prefer_server_ciphers Bật;
    ssl_session_cache được chia sẻ:SSL:10m;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_dhparam /etc/ssl/certs/dhparam.pem;
    ssl_ciphers '...
    ssl_certificate /...crt;
    khóa ssl_certificate_key /.....;

    add_header x-frame-options "SAMEORIGIN" luôn luôn;
    add_header x-xss-protection "1; mode=block" luôn;
    add_header X-Content-Type-Options nosniff;
    add_header Giao thông vận tải nghiêm ngặt-An ninh "max-age=63072000; bao gồm tên miền phụ; $

    gốc /var/www/www.example.com;
    chỉ số index.php;

  client_max_body_size 10M;
  truy cập_log /var/log/nginx/example.com.log;
  error_log /var/log/nginx/example.com.error.log lỗi;

địa điểm / {
    try_files $uri $uri/ /index.php;
}

địa điểm /mua sắm/ {
        chỉ mục index.php index.html index.htm;
        viết lại ^/shop/wp-json/(.*?)$ /shopping/index.php?rest_route=/$1 cuối cùng;
        try_files $uri $uri/ /shop/index.php?q=$uri&$args;
}
vị trí ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
        hết hạn 24h;
        log_not_found tắt;
}

    vị trí ~ \.php$ {
    try_files $uri =404;
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    fastcgi_pass unix:/var/run/php-fpm.sock;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    bao gồm fastcgi_params;

 }
vị trí ~\.(log|save|htaccess|json|csv|txt|xls)$ {
     Phủ nhận tất cả;
     error_page 403 =404 / ;
 }
    vị trí ~* /(?:uploads|files)/.*\.php$ {
        Phủ nhận tất cả;
}
lá cờ jp
Vấn đề của bạn là trong ứng dụng PHP của bạn chứ không phải trong `nginx`.
Greg avatar
lá cờ in
Bạn có thể vui lòng giải thích? Nó sẽ được nhiều đánh giá cao!
lá cờ jp
Yêu cầu tới `//etc/passwd` sẽ khớp với `location '/'` và trừ khi bạn có tệp `/var/www/www.example.com/etc/passwd` nó sẽ được xử lý bởi `index.php` thông qua `fastcgi_pass`.
lá cờ cn
SELinux được thiết kế để ngăn chặn chính xác điều này trên các hệ thống RHEL. Tôi không quen thuộc với AppArmor. Về mặt hiệu quả, SELinux chỉ cho phép một quy trình truy cập những thứ phù hợp với ngữ cảnh của chúng. Nó sẽ giảm thiểu vấn đề này, nhưng @AlexD đã đúng - vấn đề là do ứng dụng PHP.
Greg avatar
lá cờ in
Vì một lý do bí ẩn nào đó, một số thư mục đã được sao chép vào thư mục gốc của trang web gây ra lỗi này /var/www/ www.example.com/etc/passwd Thật tiếc là tôi đã không phát hiện ra điều này sớm hơn!
djdomi avatar
lá cờ za
trong trường hợp bạn đã giải quyết được vấn đề của mình, vui lòng thêm câu trả lời và chấp nhận nó sau này, nếu không chúng tôi sẽ được ghi nhớ cho đến tận thế giới về nó
Điểm:0
lá cờ in

Không có gì sai với cấu hình nginx. Một anh chàng nhà phát triển nào đó đã tạo ra một bản sao của /ect/passw vào trong /var/www/www.example.com/etc/passwd Vì vậy, đó là lý do tại sao tôi có thể duyệt/tải xuống và đó là lý do tại sao máy quét PCI của tôi bị lỗi. Xin lỗi vì đã làm mất thời gian của bạn!

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.