คำถามติดแท็ก security

หัวข้อที่เกี่ยวข้องกับความปลอดภัยของแอปพลิเคชันและการโจมตีซอฟต์แวร์ โปรดอย่าใช้แท็กนี้เพียงอย่างเดียวซึ่งส่งผลให้เกิดความกำกวม หากคำถามของคุณไม่เกี่ยวกับปัญหาการเขียนโปรแกรมที่เฉพาะเจาะจงโปรดลองถามคำถามที่ Information Security SE: https://security.stackexchange.com แทน

12
คำแนะนำที่ชัดเจนเกี่ยวกับการรับรองความถูกต้องของเว็บไซต์ที่ใช้แบบฟอร์ม [ปิด]
ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน3 ปีที่ผ่านมา การพิสูจน์ตัวตนแบบฟอร์มสำหรับเว็บไซต์ เราเชื่อว่า Stack Overflow ไม่ควรเป็นเพียงแหล่งข้อมูลสำหรับคำถามทางเทคนิคที่เฉพาะเจาะจงเท่านั้น "การรับรองความถูกต้องตามรูปแบบสำหรับเว็บไซต์" ควรเป็นหัวข้อที่ดีสำหรับการทดสอบดังกล่าว ควรรวมหัวข้อต่างๆเช่น: วิธีเข้าสู่ระบบ วิธีออกจากระบบ วิธีการยังคงอยู่ในระบบ การจัดการคุกกี้ (รวมถึงการตั้งค่าที่แนะนำ) การเข้ารหัส SSL / HTTPS วิธีการจัดเก็บรหัสผ่าน ใช้คำถามลับ ลืมฟังก์ชั่นชื่อผู้ใช้ / รหัสผ่าน การใช้noncesเพื่อป้องกันการปลอมแปลงข้ามไซต์ (CSRF) OpenID ช่องทำเครื่องหมาย "จดจำฉัน" การเติมข้อความอัตโนมัติของเบราว์เซอร์ของชื่อผู้ใช้และรหัสผ่าน URL ลับ ( URLสาธารณะป้องกันโดยสรุป) ตรวจสอบความแข็งแรงของรหัสผ่าน การตรวจสอบอีเมล และอีกมากมายเกี่ยวกับการ รับรองความถูกต้องตามแบบฟอร์ม ... ไม่ควรมีสิ่งต่าง ๆ เช่น: บทบาทและการอนุญาต การพิสูจน์ตัวตนพื้นฐาน HTTP …

7
เหตุใด Google จึงเสริมขณะ (1) ตอบสนองต่อ JSON ของพวกเขา
ทำไม Google เสริมwhile(1);ต่อการตอบสนอง JSON (ส่วนตัว) ของพวกเขา ตัวอย่างเช่นต่อไปนี้เป็นการตอบสนองขณะเปิดและปิดปฏิทินในGoogle ปฏิทิน : while (1); [ ['u', [ ['smsSentFlag', 'false'], ['hideInvitations', 'false'], ['remindOnRespondedEventsOnly', 'true'], ['hideInvitations_remindOnRespondedEventsOnly', 'false_true'], ['Calendar ID stripped for privacy', 'false'], ['smsVerifiedFlag', 'true'] ]] ] ฉันจะสมมติว่านี่คือการป้องกันไม่ให้คนทำeval()มัน แต่สิ่งที่คุณต้องทำคือแทนที่มันwhileแล้วคุณจะถูกตั้งค่า ฉันจะสันนิษฐานการป้องกัน eval เพื่อให้แน่ใจว่าคนเขียนรหัสแยกปลอดภัย JSON ฉันได้เห็นนี้ใช้ในคู่ของสถานที่อื่น ๆ ด้วย แต่มากขึ้นเพื่อให้กับ Google (จดหมายปฏิทิน, รายชื่อ, ฯลฯ ) แปลกพอGoogle Docsเริ่มต้นด้วยการ&&&START&&&แทนและ Google …
4075 javascript  json  ajax  security 

17
เพราะเหตุใดอักขระ char [] จึงนิยมใช้ String สำหรับรหัสผ่าน
ใน Swing ฟิลด์รหัสผ่านมีเมธอดgetPassword()(return char[]) แทนที่จะเป็นเมธอดปกติgetText()(return String) ในทำนองเดียวกันฉันเจอข้อเสนอแนะที่จะไม่ใช้Stringในการจัดการรหัสผ่าน เหตุใดจึงStringเป็นภัยคุกคามต่อความปลอดภัยเมื่อต้องใช้รหัสผ่าน char[]มันให้ความรู้สึกไม่สะดวกในการใช้งาน
3422 java  string  security  passwords  char 

28
ฉันจะป้องกันการฉีด SQL ใน PHP ได้อย่างไร?
คำตอบของคำถามนี้เป็นความพยายามของชุมชน แก้ไขคำตอบที่มีอยู่เพื่อปรับปรุงโพสต์นี้ ขณะนี้ไม่ยอมรับคำตอบหรือการโต้ตอบใหม่ วิธีนี้จะช่วยให้คุณเข้าถึงสแต็คโอเวอร์โฟลว์ที่ซ้อนทับกันบน: การจัดการกับ SQL หรือไม่ SQL-инъекцийв PHP? หากการป้อนข้อมูลของผู้ใช้ถูกแทรกโดยไม่มีการดัดแปลงลงในแบบสอบถาม SQL แอปพลิเคชันจะเสี่ยงต่อการฉีด SQLเช่นในตัวอย่างต่อไปนี้: $unsafe_variable = $_POST['user_input']; mysql_query("INSERT INTO `table` (`column`) VALUES ('$unsafe_variable')"); นั่นเป็นเพราะผู้ใช้สามารถป้อนสิ่งที่ชอบvalue'); DROP TABLE table;--และแบบสอบถามจะกลายเป็น: INSERT INTO `table` (`column`) VALUES('value'); DROP TABLE table;--') สิ่งที่สามารถทำได้เพื่อป้องกันไม่ให้สิ่งนี้เกิดขึ้น?

26
ฉันจะเข้าหาที่เก็บรหัสผ่านของผู้ใช้อย่างมีจริยธรรมเพื่อการดึงข้อความธรรมดาในภายหลังได้อย่างไร?
ล็อคแล้ว คำถามและคำตอบนี้ถูกล็อคเนื่องจากคำถามอยู่นอกหัวข้อ แต่มีความสำคัญทางประวัติศาสตร์ ขณะนี้ไม่ยอมรับคำตอบหรือการโต้ตอบใหม่ เนื่องจากฉันยังคงสร้างเว็บไซต์และเว็บแอปพลิเคชั่นมากขึ้นเรื่อย ๆ ฉันมักถูกถามให้เก็บรหัสผ่านของผู้ใช้ในวิธีที่พวกเขาสามารถเรียกคืนได้หาก / เมื่อผู้ใช้มีปัญหา โทรศัพท์และอื่น ๆ ) เมื่อฉันสามารถต่อสู้กับการฝึกฝนนี้อย่างขมขื่นและฉันได้เขียนโปรแกรม 'พิเศษ' มากมายเพื่อให้สามารถรีเซ็ตรหัสผ่านและความช่วยเหลือด้านการดูแลระบบได้โดยไม่ต้องเก็บรหัสผ่านจริง เมื่อฉันไม่สามารถต่อสู้ (หรือชนะไม่ได้) จากนั้นฉันก็เข้ารหัสรหัสผ่านด้วยวิธีใดวิธีหนึ่งเพื่อให้อย่างน้อยที่สุดจะไม่ถูกจัดเก็บเป็นข้อความธรรมดาในฐานข้อมูล - แม้ว่าฉันจะรู้ว่าถ้าฐานข้อมูลของฉันถูกแฮ็ก มันจะไม่ใช้เวลามากนักสำหรับผู้ร้ายที่จะถอดรหัสรหัสผ่านดังนั้นมันทำให้ฉันรู้สึกไม่สบายใจ ในโลกที่สมบูรณ์แบบผู้คนจะอัปเดตรหัสผ่านบ่อยครั้งและไม่ซ้ำกันในหลาย ๆ เว็บไซต์โชคไม่ดีที่ฉันรู้จักคนจำนวนมากที่มีรหัสผ่านการทำงาน / ที่บ้าน / อีเมล / ธนาคารเดียวกันและมอบมันให้ฉันได้อย่างอิสระ ฉันไม่ต้องการที่จะเป็นหนึ่งในความรับผิดชอบทางการเงินของพวกเขาหากกระบวนการรักษาความปลอดภัยฐานข้อมูลของฉันล้มเหลวด้วยเหตุผลบางอย่าง ฉันรู้สึกรับผิดชอบและถูกต้องตามหลักจริยธรรมและจริยธรรมในการปกป้องสิ่งที่เป็นไปได้สำหรับผู้ใช้บางคนแม้ว่าพวกเขาจะปฏิบัติต่อมันด้วยความเคารพน้อยกว่ามาก ฉันมั่นใจว่ามีช่องทางมากมายในการเข้าหาและโต้แย้งเพื่อทำแฮ็ลเกลือและตัวเลือกการเข้ารหัสที่แตกต่างกัน แต่มี 'แนวปฏิบัติที่ดีที่สุด' เดียวเมื่อคุณต้องจัดเก็บ ในเกือบทุกกรณีฉันใช้ PHP และ MySQL ถ้านั่นสร้างความแตกต่างในวิธีที่ฉันควรจัดการกับข้อมูลเฉพาะ ข้อมูลเพิ่มเติมสำหรับเงินรางวัล ฉันต้องการชี้แจงว่าฉันรู้ว่านี่ไม่ใช่สิ่งที่คุณต้องทำและในกรณีส่วนใหญ่การปฏิเสธที่จะทำดีที่สุด อย่างไรก็ตามฉันไม่ได้มองหาการบรรยายเกี่ยวกับข้อดีของการใช้วิธีการนี้ฉันกำลังมองหาขั้นตอนที่ดีที่สุดที่จะทำหากคุณใช้วิธีนี้ ในหมายเหตุด้านล่างนี้ฉันได้ชี้ให้เห็นว่าเว็บไซต์ที่มุ่งเน้นไปที่ผู้สูงอายุที่มีปัญหาทางด้านจิตใจหรือเด็กมากอาจสร้างความสับสนให้กับผู้คนเมื่อพวกเขาถูกขอให้ดำเนินการกู้คืนรหัสผ่านที่ปลอดภัย แม้ว่าเราอาจพบว่าง่ายและธรรมดาในกรณีเหล่านั้นผู้ใช้บางคนต้องการความช่วยเหลือเป็นพิเศษจากการมีเทคโนโลยีบริการช่วยเหลือพวกเขาในระบบหรือส่งอีเมล / แสดงโดยตรงกับพวกเขา ในระบบดังกล่าวอัตราการขัดสีจากกลุ่มประชากรเหล่านี้อาจทำให้แอปพลิเคชันสั่นไหวหากผู้ใช้ไม่ได้รับความช่วยเหลือในการเข้าถึงระดับนี้ดังนั้นโปรดตอบด้วยการตั้งค่าเช่นนี้ ขอบคุณทุกคน …

14
แฮชและเกลือที่ปลอดภัยสำหรับรหัสผ่าน PHP
ปัจจุบันมีการกล่าวกันว่า MD5 นั้นไม่ปลอดภัยบางส่วน เมื่อคำนึงถึงเรื่องนี้ฉันต้องการทราบว่ากลไกใดที่จะใช้สำหรับการป้องกันรหัสผ่าน คำถามนี้คือ“ การแฮ็ชสองเท่า” รหัสผ่านมีความปลอดภัยน้อยกว่าเพียงแค่การแฮชครั้งเดียวหรือไม่? แนะนำว่าการแฮ็กหลายครั้งอาจเป็นความคิดที่ดีในขณะที่วิธีการใช้การป้องกันด้วยรหัสผ่านสำหรับแต่ละไฟล์ แนะนำให้ใช้เกลือ ฉันใช้ PHP ฉันต้องการระบบเข้ารหัสรหัสผ่านที่ปลอดภัยและรวดเร็ว การแฮ็กรหัสผ่านเป็นล้านครั้งอาจปลอดภัยกว่า แต่ก็ช้าลงเช่นกัน วิธีการบรรลุสมดุลที่ดีระหว่างความเร็วและความปลอดภัย? นอกจากนี้ฉันต้องการผลลัพธ์ที่จะมีจำนวนตัวอักษรคงที่ กลไกการแปลงแป้นพิมพ์ต้องพร้อมใช้งานใน PHP มันจะต้องปลอดภัย มันสามารถใช้เกลือได้ (ในกรณีนี้เกลือทั้งหมดนั้นดีเท่ากันหรือไม่มีวิธีใดที่จะสร้างเกลือที่ดี?) นอกจากนี้ฉันควรเก็บสองฟิลด์ในฐานข้อมูล (ตัวอย่างเช่นใช้ MD5 และอีกฟิลด์หนึ่งใช้ SHA เป็นต้น) มันจะทำให้ปลอดภัยหรือไม่ปลอดภัยหรือไม่? ในกรณีที่ฉันยังไม่ชัดเจนพอฉันต้องการทราบว่าควรใช้ฟังก์ชัน hashing ใดและวิธีเลือกเกลือที่ดีเพื่อให้มีกลไกการป้องกันรหัสผ่านที่ปลอดภัยและรวดเร็ว คำถามที่เกี่ยวข้องที่ไม่ค่อยครอบคลุมคำถามของฉัน: ความแตกต่างระหว่าง SHA และ MD5 ในการ เข้ารหัสรหัสผ่านPHP อย่างง่าย วิธีการรักษาความปลอดภัยในการจัดเก็บคีย์รหัสผ่านสำหรับ asp.net คุณจะใช้รหัสผ่านเค็มใน Tomcat 5.5 อย่างไร

17
ฉันจะฆ่าเชื้ออินพุตของผู้ใช้ด้วย PHP ได้อย่างไร
มีฟังก์ชั่น catchall บางแห่งที่ทำงานได้ดีสำหรับฆ่าเชื้ออินพุตของผู้ใช้สำหรับการฉีด SQL และการโจมตี XSS ในขณะที่ยังอนุญาตแท็ก HTML บางประเภทอยู่?

13
การฉีด SQL จากการ์ตูน "Bobby Tables" XKCD ทำงานอย่างไร
แค่มองไปที่: (ที่มา: https://xkcd.com/327/ ) SQL นี้ทำอะไร: Robert'); DROP TABLE STUDENTS; -- ฉันรู้ว่าทั้งสอง'และ--สำหรับความคิดเห็น แต่คำไม่DROPได้รับความเห็นเช่นกันเพราะมันเป็นส่วนหนึ่งของบรรทัดเดียวกันหรือไม่

18
วิธีปฏิบัติที่ดีที่สุดสำหรับการรักษาความปลอดภัย REST API / บริการบนเว็บ [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน2 ปีที่ผ่านมา เมื่อออกแบบ REST API หรือบริการจะมีแนวทางปฏิบัติที่ดีที่สุดสำหรับการจัดการด้านความปลอดภัย (การรับรองความถูกต้องการอนุญาตการจัดการข้อมูลผู้ใช้)? เมื่อสร้าง SOAP API คุณจะต้องมี WS-Security เป็นแนวทางและมีเอกสารมากมายในหัวข้อ ฉันพบข้อมูลน้อยลงเกี่ยวกับการรักษาจุดสิ้นสุด REST ในขณะที่ฉันเข้าใจว่า REST โดยเจตนาไม่มีข้อกำหนดเหมือนกับ WS- * ฉันหวังว่าวิธีปฏิบัติที่ดีที่สุดหรือรูปแบบที่แนะนำได้เกิดขึ้นแล้ว การอภิปรายหรือลิงค์ไปยังเอกสารที่เกี่ยวข้องจะได้รับการชื่นชมอย่างมาก หากเป็นเรื่องสำคัญเราจะใช้ WCF กับข้อความ POX / JSON ต่อเนื่องสำหรับ REST API ของเรา / บริการที่สร้างโดยใช้ v3.5 ของ. NET Framework

30
จะหลีกเลี่ยงวิศวกรรมย้อนกลับของไฟล์ APK ได้อย่างไร
ฉันกำลังพัฒนาแอปประมวลผลการชำระเงินสำหรับ Android และฉันต้องการป้องกันไม่ให้แฮ็กเกอร์เข้าถึงทรัพยากรทรัพย์สินหรือซอร์สโค้ดจากไฟล์APK หากมีคนเปลี่ยนนามสกุล. apk ให้เป็น. zip พวกเขาสามารถคลายซิปและเข้าถึงทรัพยากรและทรัพย์สินทั้งหมดของแอปได้อย่างง่ายดายและใช้dex2jarและตัวถอดรหัสของ Java พวกเขายังสามารถเข้าถึงซอร์สโค้ดได้ มันง่ายมากที่จะทำวิศวกรรมย้อนกลับไฟล์ Android เอพีเค - สำหรับรายละเอียดเพิ่มเติมโปรดดูที่กองมากเกินคำถามวิศวกรรมย้อนกลับจากไฟล์ APK โครงการ ฉันใช้เครื่องมือ Proguard ที่มาพร้อมกับ Android SDK เมื่อฉันแปลงไฟล์ APK ที่สร้างโดยใช้ keystore ที่ลงนามแล้วและ Proguard ฉันจะได้รับรหัสที่สับสน อย่างไรก็ตามชื่อของส่วนประกอบ Android ยังคงไม่เปลี่ยนแปลงและบางรหัสเช่นรหัสคีย์ที่ใช้ในแอพยังคงไม่เปลี่ยนแปลง ตามเอกสารของ Proguard เครื่องมือไม่สามารถทำให้ส่วนประกอบสับสนที่กล่าวถึงในไฟล์มานิเฟสต์ ตอนนี้คำถามของฉันคือ: ฉันจะป้องกันวิศวกรรมย้อนกลับของ APK Android ได้อย่างสมบูรณ์ได้อย่างไร เป็นไปได้ไหม ฉันจะปกป้องทรัพยากรทรัพย์สินและซอร์สโค้ดทั้งหมดของแอปเพื่อให้แฮกเกอร์ไม่สามารถแฮ็คไฟล์ APK ในทางใดทางหนึ่งได้อย่างไร มีวิธีใดที่จะทำให้การแฮ็กยากขึ้นหรือเป็นไปไม่ได้ ฉันสามารถทำอะไรได้อีกเพื่อปกป้องซอร์สโค้ดในไฟล์ APK ของฉัน

7
PDO มีการจัดทำงบที่เพียงพอเพื่อป้องกันการฉีด SQL หรือไม่?
สมมติว่าฉันมีรหัสเช่นนี้: $dbh = new PDO("blahblah"); $stmt = $dbh->prepare('SELECT * FROM users where username = :username'); $stmt->execute( array(':username' => $_REQUEST['username']) ); เอกสาร PDO พูดว่า: ไม่จำเป็นต้องอ้างพารามิเตอร์ของคำสั่งที่เตรียมไว้ คนขับจัดการกับมันให้คุณ นั่นคือทั้งหมดที่ฉันต้องทำเพื่อหลีกเลี่ยงการฉีด SQL? มันง่ายจริงๆเหรอ? คุณสามารถสมมติว่า MySQL ถ้ามันสร้างความแตกต่าง นอกจากนี้ฉันแค่อยากรู้เกี่ยวกับการใช้งบเตรียมกับการฉีด SQL ในบริบทนี้ฉันไม่สนใจ XSS หรือช่องโหว่อื่น ๆ

14
เหตุใด OAuth v2 จึงมีทั้งโทเค็นการเข้าถึงและรีเฟรช
ส่วน 4.2 ของร่างโปรโตคอล OAuth 2.0 ระบุว่าเซิร์ฟเวอร์การอนุญาตสามารถส่งคืนทั้งสองได้ access_token (ซึ่งใช้ในการตรวจสอบสิทธิ์ของตัวเองด้วยทรัพยากร) เช่นเดียวกับ a refresh_tokenซึ่งใช้เพื่อสร้างใหม่อย่างแท้จริงaccess_token: https://tools.ietf.org/html/rfc6749#section-4.2 ทำไมถึงมีทั้งคู่? ทำไมไม่เพียงแค่ทำให้access_tokenครั้งสุดท้ายตราบเท่าที่refresh_tokenและไม่มีrefresh_token?

4
การฉีด SQL ที่ได้รับรอบ mysql_real_escape_string ()
มีความเป็นไปได้ในการฉีด SQL แม้ว่าจะใช้mysql_real_escape_string()ฟังก์ชันอยู่หรือไม่ พิจารณาสถานการณ์ตัวอย่างนี้ SQL ถูกสร้างใน PHP ดังนี้: $login = mysql_real_escape_string(GetFromPost('login')); $password = mysql_real_escape_string(GetFromPost('password')); $sql = "SELECT * FROM table WHERE login='$login' AND password='$password'"; ฉันเคยได้ยินคนจำนวนมากพูดกับฉันว่ารหัสเช่นนั้นยังคงเป็นอันตรายและเป็นไปได้ที่จะแฮ็กแม้จะmysql_real_escape_string()ใช้ฟังก์ชั่น แต่ฉันไม่สามารถคิดถึงการหาประโยชน์ที่เป็นไปได้ใด ๆ การฉีดแบบคลาสสิคเช่นนี้: aaa' OR 1=1 -- ไม่ทำงาน. คุณรู้หรือไม่ว่าการฉีดใด ๆ ที่เป็นไปได้ซึ่งจะได้รับผ่านโค้ด PHP ข้างต้น?

11
การรับรองความถูกต้องกับการอนุญาต
บริบทของเว็บแอปพลิเคชันแตกต่างกันอย่างไร ฉันเห็นตัวย่อ "รับรองความถูกต้อง" มาก มันหมายถึงการรับรองความถูกต้องหรือการรับรองความถูกต้องหรือไม่ หรือเป็นทั้งสองอย่าง?

4
bcrypt มีเกลือในตัวได้อย่างไร
บทความของ Coda Hale "วิธีเก็บรหัสผ่านอย่างปลอดภัย"อ้างว่า: bcrypt มีเกลือในตัวเพื่อป้องกันการโจมตีของตารางสายรุ้ง เขาอ้างอิงบทความนี้ซึ่งกล่าวว่าในการดำเนินการของ OpenBSD bcrypt: OpenBSD สร้างเกลือ bcrypt 128- บิตจากกระแสหลักของ arcfour (arc4random (3)) ซึ่งประกอบด้วยข้อมูลแบบสุ่มที่เคอร์เนลรวบรวมจากการจับเวลาอุปกรณ์ ฉันไม่เข้าใจวิธีการทำงานนี้ ในความคิดของฉันของเกลือ: มันจะต้องแตกต่างกันสำหรับแต่ละรหัสผ่านที่เก็บไว้ดังนั้นตารางสายรุ้งแยกต่างหากจะต้องถูกสร้างขึ้นสำหรับแต่ละรหัส จำเป็นต้องเก็บไว้ที่ไหนสักแห่งเพื่อให้สามารถทำซ้ำได้: เมื่อผู้ใช้พยายามเข้าสู่ระบบเราใช้ความพยายามรหัสผ่านของพวกเขาทำซ้ำขั้นตอนเกลือและแฮชเดียวกันกับที่เราทำเมื่อเราเก็บรหัสผ่านเดิมและเปรียบเทียบ เมื่อฉันใช้ Devise (ผู้จัดการการเข้าสู่ระบบ Rails) กับ bcrypt ไม่มีคอลัมน์เกลือในฐานข้อมูลดังนั้นฉันจึงสับสน หากเกลือถูกสุ่มและไม่ได้เก็บไว้ที่ใดเราจะทำขั้นตอนการแฮชซ้ำได้อย่างน่าเชื่อถือได้อย่างไร ในระยะสั้นbcrypt สามารถมีเกลือในตัวได้อย่างไร

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.