वेब साइट प्रोग्रामिंग भेद्यता के लिए चेकलिस्ट

Question

एसओ ऑनलाइन देखना मेरे लिए काफी शिक्षा रही है। मैं वेब साइटों के खिलाफ उपयोग की जाने वाली विभिन्न क्षमताओं और शोषणों की एक चेकलिस्ट बनाना चाहता हूं, और उनके खिलाफ बचाव के लिए कौन सी प्रोग्रामिंग तकनीकों का उपयोग किया जा सकता है।

• vunerabilities की कौन सी श्रेणियां?
  • क्रैश होने साइट
  • सर्वर
  • अन्य लोगों के लॉगिन में घुसपैठ करने
  • स्पैम
  • sockpuppeting में तोड़कर, meatpuppeting
  • आदि ...
• रक्षात्मक प्रोग्रामिंग तकनीक किस तरह का ?
• आदि ...

Answer 1

से

Open Web Application Security Project:

1. OWASP Top Ten कमजोरियों (पीडीएफ)
2. एक और अधिक दर्दनाक व्यापक सूची के लिए: Category:Vulnerability

शीर्ष दस हैं:

1. पार साइट स्क्रिप्टिंग (एक्सएसएस)
,210
2. इंजेक्शन खामियों (एसक्यूएल इंजेक्शन, स्क्रिप्ट इंजेक्शन)
3. दुर्भावनापूर्ण फ़ाइल निष्पादन
4. असुरक्षित प्रत्यक्ष वस्तु संदर्भ
5. क्रॉस-साइट अनुरोध जालसाजी (XSRF)
6. सूचना रिसाव और अनुचित त्रुटि
7. टूटी प्रमाणीकरण हैंडलिंग और सत्र प्रबंधन
8. असुरक्षित क्रिप्टोग्राफिक भंडारण
9. असुरक्षित संचार
10. Failu यूआरएल एक्सेस को प्रतिबंधित करने के लिए

Answer 2

एसक्यूएल इंजेक्शन

Answer 3

XSS (क्रॉस साइट स्क्रिप्टिंग) हमलों

Answer 4

जाहिर कमजोरियों के लिए हर क्षेत्र का परीक्षण:

• एसक्यूएल - तार से बचने के (जैसे mysql_real_escape_string)
• एक्सएसएस
• एचटीएमएल नहीं विशेष उद्देश्य के thatis है कि क्षेत्र के लिए

अनंत छोरों के लिए खोज (केवल अप्रत्यक्ष बात बनाया गया था इनपुट फ़ील्ड (XSS की एक अच्छा संकेत आमतौर पर)

कुछ भी और से मुद्रित किया जा रहा (एक बहुत अगर लोगों ने इसे गलती से पाया) जो वास्तव में एक सर्वर को मार सकता है)।

Answer 5

पर्यवेक्षण और आसानी से ठीक करने के लिए आसान: ग्राहक पक्ष से प्राप्त डेटा की सफाई। ';' जैसी चीजों की जांच आपके आवेदन में दुर्भावनापूर्ण कोड इंजेक्शन को रोकने में मदद कर सकता है।

Answer 6

मैं ओडब्ल्यूएएसपी जानकारी को एक मूल्यवान संसाधन के रूप में दूसरा स्थान देता हूं। निम्नलिखित, साथ ही रुचि का हो सकता विशेष रूप से हमले पैटर्न:

• CERT Top 10 Secure Coding Practices
• Common Attack Pattern Enumeration and Classification
• Attack Patterns
• Secure Programming for Linux and Unix
• A Taxonomy of Coding Errors that Affect Security
• Secure Programming with Static Analysis Presentation

Answer 7

G'day,

सुरक्षा के लिए एक अच्छा स्थैतिक विश्लेषण उपकरण डेविड व्हीलर द्वारा लिखित FlawFinder है। यह विभिन्न सुरक्षा शोषण की तलाश में एक अच्छा काम करता है,

हालांकि, यह आपके कोड के माध्यम से किसी ज्ञात व्यक्ति को पढ़ने की जगह नहीं लेता है। जैसा कि डेविड अपने वेब पेज पर कहता है, "एक उपकरण के साथ एक मूर्ख अभी भी मूर्ख है!"

एचटीएच।

चियर्स, रोब

Answer 8

कुछ रोकथाम की तकनीक:

XSS

• आप कोई पैरामीटर/उपयोगकर्ता से इनपुट लेने के लिए और कभी भी एक लॉग में यह outputting पर योजना है, चाहे तो या एक वेब पेज, इसे स्वच्छ करें (एचटीएमएल, उद्धरण, जावास्क्रिप्ट जैसा कुछ भी पट्टी/बचें ...) यदि आप अपने भीतर एक पृष्ठ के वर्तमान यूआरआई को प्रिंट करते हैं, तो sanitize! यहां तक ​​कि PHP_SELF प्रिंटिंग, उदाहरण के लिए, असुरक्षित है। स्वच्छ! प्रतिबिंबित एक्सएसएस ज्यादातर अनिश्चित पृष्ठ पैरामीटर से आता है।

• यदि आप उपयोगकर्ता से कोई इनपुट लेते हैं और इसे सहेजते हैं या प्रिंट करते हैं, तो उन्हें चेतावनी दें कि कुछ खतरनाक/अमान्य पता चला है और उन्हें फिर से इनपुट किया गया है। एक आईडीएस पहचान के लिए अच्छा है (जैसे कि PHPIDS।) फिर भंडारण/प्रिंटिंग से पहले sanitize। फिर जब आप भंडारण/डेटाबेस से कुछ प्रिंट करते हैं, फिर से sanitize! इनपुट -> आईडीएस/sanitize -> स्टोर -> sanitize -> आउटपुट

• संभावित रूप से कमजोर कोड को स्थानांतरित करने में सहायता के लिए विकास के दौरान कोड स्कैनर का उपयोग करें।

XSRF

• कभी विनाशकारी कार्यक्षमता के लिए GET अनुरोध है, यानी एक पोस्ट को हटाने का उपयोग करें। इसके बजाय, केवल POST अनुरोध स्वीकार करते हैं। इसे हैकर के लिए अतिरिक्त आसान बनाता है।
• रेफरर जाँच हो रही है यकीन है कि अनुरोध बनाने के लिए आपकी साइट से आने नहीं काम करता है। रेफरर को धोखा देना मुश्किल नहीं है।
• एक यादृच्छिक हैश का उपयोग टोकन के रूप में करें जो प्रत्येक अनुरोध में मौजूद और मान्य होना चाहिए, और यह थोड़ी देर के बाद समाप्त हो जाएगा। एक छिपे हुए फॉर्म फ़ील्ड में टोकन प्रिंट करें और फॉर्म पोस्ट होने पर सर्वर की ओर से जांचें। बुरे लोगों को अनुरोध करने के लिए सही टोकन की आपूर्ति करनी होगी, और यदि वे वास्तविक टोकन प्राप्त करने में कामयाब रहे हैं, तो इसे समाप्त होने से पहले होना आवश्यक होगा।

एसक्यूएल इंजेक्शन

• अपने ORM या डाटाबेस अमूर्त वर्ग तरीकों प्रतिबंध लगाया होना चाहिए - उन्हें, हमेशा का उपयोग करें। यदि आप ओआरएम या डीबी अबास्ट्रक्शन क्लास का उपयोग नहीं कर रहे हैं ... आपको होना चाहिए।

Answer 9

आप अच्छा फ़ायरफ़ॉक्स एडऑन Security Compass से कई खामियों और XSS और एसक्यूएल इंजेक्शन की तरह कमजोरियों का परीक्षण करने के मिल सकता है। बहुत बुरा वे फ़ायरफ़ॉक्स 3.0 पर काम नहीं करते हैं। मुझे आशा है कि जल्द ही उन्हें अपडेट किया जाएगा।