ความไม่มั่นคงในการตั้งค่า PHP ทั่วไป?

10

ฉันทำงานกับการบริหารระบบที่มหาวิทยาลัยแห่งหนึ่งและเพิ่งพบเจอสิ่งที่อาจเป็นเรื่องธรรมดา แต่ก็น่าตกใจสำหรับฉัน

ไดเร็กทอรี public_html และพื้นที่เว็บทั้งหมดถูกจัดเก็บใน afs พร้อมสิทธิ์การอ่านสำหรับเว็บเซิร์ฟเวอร์ เนื่องจากผู้ใช้ได้รับอนุญาตให้มีสคริปต์ php ใน public_html ของพวกเขาซึ่งหมายความว่าพวกเขาสามารถเข้าถึงไฟล์ของกันและกันได้จากภายใน php (และไฟล์เว็บหลัก!)

สิ่งนี้ไม่เพียงทำให้การป้องกันด้วยรหัสผ่าน. htaccess ไร้ประโยชน์อย่างสมบูรณ์ แต่ยังช่วยให้ผู้ใช้สามารถอ่านไฟล์ต้นฉบับ php ที่มีรหัสผ่านฐานข้อมูล mysql และข้อมูลที่ละเอียดอ่อนที่คล้ายกัน หรือถ้าพวกเขาพบว่าคนอื่นมีไดเรกทอรีที่เว็บเซิร์ฟเวอร์มีการเข้าถึงการเขียน (เช่นบันทึกส่วนตัวหรือบันทึกข้อมูลแบบฟอร์มที่ส่ง) พวกเขาสามารถจัดเก็บไฟล์ในบัญชีเหล่านั้น

ตัวอย่างง่ายๆ:

<?
  header("Content-type: text/plain");
  print file_get_contents("/afs/example.com/home/smith/public_html/.htpasswd"); 
?>

นี่เป็นปัญหาที่พบบ่อยหรือไม่? และโดยทั่วไปคุณจะแก้ปัญหาได้อย่างไร

UPDATE:

ขอบคุณสำหรับการป้อนข้อมูล น่าเสียดายที่ไม่มีคำตอบง่ายๆ ในสภาพแวดล้อมที่ใช้ร่วมกันขนาดใหญ่เช่นนี้ผู้ใช้อาจไม่ได้รับตัวเลือกมากมาย วิธีที่ดีที่สุดที่ฉันคิดคือตั้ง "open_basedir" ในการกำหนดค่าหลักสำหรับไดเรกทอรี "public_html" ทั้งหมดเรียกใช้ suphp และอนุญาตเฉพาะ php ที่สะอาด (ไม่มีสคริปต์ cgi, เรียกใช้คำสั่งภายนอกกับ backticks ฯลฯ )

การเปลี่ยนแปลงนโยบายเช่นนี้จะทำให้หลายสิ่งแตกต่างกันและอาจทำให้ผู้ใช้จับโกยและไล่ล่าพวกเรา ... ฉันจะพูดคุยกับเพื่อนร่วมงานของฉันและอัปเดตที่นี่หากเราตัดสินใจว่าจะเปลี่ยนการตั้งค่าอย่างไร

apache-2.2 security php

— พอนทัส
แหล่งที่มา

นี่เป็นคำถามที่น่าสนใจ ฉันแน่ใจว่าผู้ให้บริการโฮสติ้งที่ใช้ร่วมกันรายใหญ่ (เช่น DreamHost) เป็นไปไม่ได้ แต่ฉันสนใจที่จะปกป้องพวกเขาจากสิ่งนี้ suphp ตามที่กล่าวไว้ใน cstamas ดูเหมือนจะเป็นทางออกที่ดี แต่นี่คือสิ่งที่ผู้ให้บริการโฮสติ้งส่วนใหญ่ใช้

— Lèsemajesté

1

ผมเคยใช้open_basedirแก้ปัญหาด้านล่างในการผลิตที่ใช้ร่วมกันระบบโฮสติ้ง แต่เราทุกคนแบ่งออกเป็น vhost ของตัวเอง - ไม่แน่ใจว่ามันเหมาะกับไดเรกทอรีเดียว ...

— voretaq7

8

หนึ่งสามารถใช้ suphp ซึ่งเรียกใช้สคริปต์ php กับ uid ของเจ้าของ

http://www.suphp.org

— cstamas
แหล่งที่มา

นี่อาจจะไม่แก้ปัญหาข้างต้น (อย่างน้อยในสภาพแวดล้อมการโฮสต์ที่แชร์ไฟล์. htpasswd มักจะเป็นของผู้ใช้ที่เป็นเจ้าของเว็บไซต์และกลุ่ม (apache) หรือโลก (เพราะผู้ใช้ไม่ทราบ / ดูแลเกี่ยวกับความปลอดภัย) อ่านได้ ดังนั้นแม้จะมี suphp พวกเขาก็สามารถอ่านไฟล์เหล่านั้นได้)

— voretaq7

@ voretaq7: สามารถใช้ข้อ จำกัด อื่น ๆ ได้ เท่าที่ฉันจำได้ว่าคุณสามารถปฏิเสธการเข้าถึงไฟล์ที่คุณไม่ได้เป็นเจ้าของ ดังนั้นการออกกฎการโจมตีดังกล่าวข้างต้น

— cstamas

ฉันรู้ว่าคุณสามารถ จำกัด การอนุญาตไฟล์ ("ไม่สามารถเขียนได้โดยกลุ่ม / อื่น ๆ / ใครก็ได้") แต่ฉันไม่รู้วิธีการบล็อกการอ่านที่นอกเหนือจากการอนุญาต FS พวกเขามีcheck_vhost_docrootแต่ AFAIK ที่ใช้กับสคริปต์ที่ถูกเรียกใช้เท่านั้น (? ฉันอาจผิดในเรื่องนั้น)

— voretaq7

1

ฉันไม่แน่ใจว่า suphp เป็นทางออกที่ดีในสภาพแวดล้อมเช่นนี้หรือไม่ ผู้ใช้อาจมีสิทธิ์ทุกประเภทที่ผู้ใช้ www ไม่มี ผู้โจมตีที่พบวิธีผ่าน php สามารถค้นหาคีย์ ssh หรือแป้นคีย์หรือเปลี่ยนสคริปต์การเข้าสู่ระบบของผู้ใช้เพื่อสร้างแบ็คดอร์ และการตั้งค่า "vhosts" ไม่เป็นประโยชน์เนื่องจากไดเรกทอรี public_html พร้อมใช้งานผ่าน "/ ~ ชื่อผู้ใช้" บนโฮสต์เสมือนหลัก ฉันคิดว่าบางทีสคริปต์ใน public_html ควรจะปิดการใช้งานอย่างสมบูรณ์

— Pontus

4

ข้อเสนอแนะของฉันจะ จำกัด การเข้าถึงไฟล์ของ PHP (ผ่านopen_basedir& คำสั่งที่คล้ายกันบนพื้นฐานต่อ vhost): คุณต้องการให้ผู้ใช้สามารถเปิด / อ่าน / เขียนไฟล์ภายใต้ webroot ของพวกเขาและอาจอยู่เหนือระดับหนึ่ง space) แต่ไม่ใช่ไดเรกทอรีที่เก็บhtpasswdไฟล์เช่น

โครงสร้างไดเรกทอรีเช่น:

/Client
    /auth
    /site
        /www_root
        /www_tmp

จะตรงตามข้อกำหนดนี้: open_basedirสามารถชี้ไปที่/Client/siteปลอดภัยและhtpasswdไฟล์ที่เก็บไว้ใน/Client/auth(ด้วย.htaccessไฟล์หรือhttpd.confแก้ไขเพื่อชี้ไปที่ตำแหน่งที่เหมาะสมแทน)
สิ่งนี้จะป้องกันไม่ให้ลูกค้าของคุณเปิดไฟล์ของคนอื่นและในฐานะที่เป็นประโยชน์ผู้ใช้ที่เป็นอันตรายไม่สามารถอ่านเนื้อหาใน/Client/auth(หรือสิ่งอื่นใดในระบบของคุณเช่น/etc/passwd:-)

ดูhttp://php.net/manual/en/ini.core.phpสำหรับรายละเอียดเพิ่มเติมเกี่ยวกับการใช้งาน open_basedir & การใช้งานต่อ vhost

— voretaq7
แหล่งที่มา

1

suphpตามที่ระบุไว้โดย cstamas เป็นความคิดที่ดีจริงๆในสภาพแวดล้อมการโฮสต์ที่ใช้ร่วมกัน - มีค่าใช้จ่ายเล็กน้อยในการตั้งค่า แต่ฉันจะบอกว่ากำไรด้านความปลอดภัยนั้นคุ้มค่า sandboxing เว็บไซต์ PHP ของคุณทั้งหมดไม่ว่าจะเป็น FreeBSD Jail หรือ virtual machine เฉพาะที่เป็นหนึ่งในความปลอดภัยที่ยิ่งใหญ่ที่สุด

— voretaq7

"open_basedir" ดูเหมือนจะเป็นวิธีที่ง่ายในการแยกไฟล์เว็บหลักจากไฟล์ผู้ใช้โดยมีเงื่อนไขว่า "public_html" ให้บริการผ่านโฮสต์เสมือนของมันเอง แต่มันไม่ได้ปกป้องผู้ใช้จากกันเนื่องจากไม่มีโฮสต์เสมือนของตัวเอง ขวา?

— Pontus

ฉันไม่ได้ลองตั้งค่าopen_basedirใน <ไดเรกทอรี> แต่ฉันคิดว่ามันควรจะอนุญาตได้ ("ลองดูและดู" - ที่เลวร้ายที่สุดมันไม่สามารถใช้งานได้ :)

— voretaq7

1

จนถึงตอนนี้ดูเหมือนว่า open_basedir คือสิ่งที่โฮสต์เว็บเชิงพาณิชย์ส่วนใหญ่ใช้ (โดยปกติแล้วสมาชิกจะมีโดเมนแบบชำระเงินของตนเองหรือรับโดเมนย่อยฟรี) แต่สำหรับ homepages ที่ใช้ไดเรกทอรีเช่นในสถาบันการศึกษา suphp ดูเหมือนจะเป็นคำตอบที่ดีที่สุด

— Lèsemajesté

1

ไม่มันไม่ใช่ปัญหาทั่วไปเพราะโฮสต์ที่แชร์กันส่วนใหญ่จะกำหนดค่า open_basedir ในไฟล์ htaccess ในไดเรกทอรี public_html ของผู้ใช้แต่ละคน (หรือใน vhost หากผู้ใช้แต่ละคนมี vhost ของตัวเอง)

เช่นไฟล์. htaccess:

# Assuming these are not set globally - its good practice to limit:
  php_flag magic_quotes_gpc off
  php_flag magic_quotes_runtime off
  php_flag register_globals off
  php_flag short_open_tag off
  php_value max_execution_time 60

# These set the user-specific paths
  php_value open_basedir /afs/example.com/home/smith:/usr/share/php/include
  php_value session.save_path /afs/example.com/home/smith/tmp
  php_value upload_tmp_dir /afs/example.com/home/smith/tmp

แต่ให้แน่ใจว่าคุณตั้งค่าสิทธิ์ที่ถูกต้องในไฟล์. htaccess เพื่อป้องกันผู้ใช้ที่เปลี่ยน open_basedir (หากพวกเขาพยายามที่จะแทนที่มันใน subdir / .htaccess มันจะไม่ทำงาน - แต่คุณควรทดสอบเพื่อให้แน่ใจ) .

HTH

ค.

— symcbean
แหล่งที่มา

2

การทำเช่นนี้อาจช่วยป้องกันบัญชีใหม่ได้ในเบื้องต้น แต่ความจริงที่ว่าผู้ใช้ไม่สามารถแก้ไขอาจทำให้ดึงดูดลบไฟล์. htaccess (ซึ่งพวกเขาสามารถทำได้เนื่องจากต้องการเพียงการเข้าถึงเพื่อเขียนไปยังไดเรกทอรี public_html) และสร้างขึ้นเอง การเพิ่ม "<Directory>" -block ในการกำหนดค่าหลักสำหรับผู้ใช้แต่ละคนจะทำงานได้ แต่ที่นี่พวกเขายังได้รับอนุญาตให้ backtick คำสั่งภายนอกจาก php ซึ่งหมายความว่า open_basedir หลีกเลี่ยงได้อย่างง่ายดาย

— Pontus

@Pontus: จุดที่ดีเกี่ยวกับการลบไฟล์ (ฉันไม่แน่ใจว่า afs รองรับแอตทริบิวต์ไฟล์ที่ไม่เปลี่ยนรูปแบบหรือไม่) ฉันจะให้ +1 ถ้าคุณบอกว่าการใช้เว็บเซิร์ฟเวอร์ในคุก chroot จะช่วยป้องกันช่องโหว่การทำงานของโปรแกรมทุกประเภท

— symcbean

1

AFS ละเว้นสิทธิ์ผู้ใช้ unix อย่างง่าย suPHP เรียกใช้งาน setuid ก่อนที่จะรันโปรแกรม php แต่นั่นไม่ได้ให้กระบวนการโทเค็น Kerberos ที่จำเป็นในการเข้าถึง AFS และถูก จำกัด สิทธิ์ suPHP จะต้องได้รับการแก้ไขด้วยวิธีใดวิธีหนึ่งเพื่อรับโทเค็นเหล่านั้นก่อนจึงจะสามารถนำเสนอระบบ AFS ในฐานะผู้ใช้รายนั้นได้ เท่าที่ฉันรู้ว่ายังไม่ได้ทำ (อันที่จริงฉันพบคำถามนี้เมื่อต้องการดูว่ามีใครทำเช่นนั้นหรือไม่)

— Charles B
แหล่งที่มา