जब एक क्लाइंट को अपनी वेबसाइट पर रिच टेक्स्ट एडिटिंग की आवश्यकता होती है तो आप क्या करते हैं?


18

जैसा कि हम सभी अब तक जानते हैं, XSS के हमले खतरनाक और खींचने में आसान होते हैं । विभिन्न रूपरेखाएँ HTML को एनकोड करना आसान बनाती हैं, जैसे ASP.NET MVC करता है:

<%= Html.Encode("string"); %>

लेकिन तब क्या होता है जब आपके क्लाइंट को आवश्यकता होती है कि वे अपनी सामग्री को सीधे Microsoft Word दस्तावेज़ से अपलोड कर सकें?

यहाँ परिदृश्य है: लोग एक WYSIWYG संपादक (इस मामले में LittleMCE ) में Microsoft शब्द से सामग्री को कॉपी और पेस्ट कर सकते हैं , और फिर उस जानकारी को एक वेब पेज पर पोस्ट किया जाता है।

वेबसाइट सार्वजनिक है, लेकिन उस संगठन के केवल सदस्यों के पास वेबपृष्ठ पर जानकारी पोस्ट करने के लिए पहुंच होगी।

मैं एक सुरक्षित तरीके से इन आवश्यकताओं को कैसे संभालूं? वर्तमान में ग्राहक के पोस्ट (केवल 'विश्वसनीय' उपयोगकर्ता पोस्ट कर सकते हैं) पर कोई जाँच नहीं की गई है, लेकिन मैं इससे विशेष रूप से खुश नहीं हूँ और खाता हैक होने की स्थिति में इसे और लॉक करना चाहूंगा।

एकमात्र वैचारिक विधि जिसके बारे में मुझे पता है कि इन आवश्यकताओं को पूरा करने के लिए HTML टैग्स को श्वेतसूची में रखना है और उन लोगों को गुजरना चाहिए । क्या कोई और तरीका है? यदि नहीं, तो किसी भी रूप में डेटाबेस में उपयोगकर्ता स्टोर इनपुट को सुरक्षित करने का एक सुरक्षित तरीका क्या है, लेकिन केवल इसे अच्छी तरह से एन्कोडेड और खराब टैग से छीन लिया गया है?

संबंधित प्रश्न

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


अच्छा सवाल- यहाँ एक समान
रिचर्डॉड

माना। यह समान है, लेकिन यह एक भ्रामक प्रश्न है (प्रश्न को खोजना कठिन है), और यह विशेष रूप से नहीं पूछता है कि क्या कोई अन्य तरीका है। यदि श्वेतसूची में HTML को प्रस्तुत किए बिना कोई अन्य तरीका है, तो मैं इसके बारे में हूँ। यदि कोई ASP.NET MVC व्यू इंजन है जो इस बात का ध्यान रखता है, तो यह भी जानना अच्छा है।
जॉर्ज स्टॉकर

गैर-सुरक्षा से संबंधित नोट पर, टैगिंग फ़िल्टरिंग शायद उपयोगकर्ता इंटरफ़ेस के परिप्रेक्ष्य से सहायक होगी। एंगल ब्रैकेट को गलती से टाइप करना और उसे बचाना बहुत आसान है। चूंकि हम उन उपयोगकर्ताओं के बारे में बात कर रहे हैं जो वर्ड से कॉपी कर रहे हैं, इसलिए यह एक अच्छा विचार है कि जो बुरे टैग की तरह दिखता है उसे पकड़ लें और उन्हें उचित तरीके से एन्कोड करें (यानी & lt;) ताकि चीजें बस काम करें।

बिंदु # 4 के बारे में: आप शर्त लगाते हैं कि यह अभी भी एक मुद्दा है! अधिकांश हैक सब के बाद एक अंदर का काम है। एक विशिष्ट संपादक के लिए, मैंने FreeTextBox का उपयोग करके सौभाग्य प्राप्त किया है, लेकिन मैं यह नहीं बोल सकता कि यह आपकी आवश्यकताओं, विशेष रूप से MVC से कितना मेल खाता है।
जोएल कोएहॉर्न

1
@gnat धन्यवाद; संपादित। ऐसा लगता है कि मेरे प्रश्न ने किसी प्रकार के काबिल का ध्यान आकर्षित किया है; तेजी से उत्तराधिकार में तीन डाउनवोट, और आपकी सुरक्षा और संपादित अनुरोध।
जॉर्ज स्टॉकर

जवाबों:


8

(एक डेवलपर के रूप में आप के लिए) सबसे आसान तरीका है शायद के कई रूपों में से एक को लागू करना है Markdown उदाहरण के लिए, Markdown.NET , या और भी बेहतर (imho), एक wmd-संपादक

फिर, आपके उपयोगकर्ता सरल HTML पेस्ट कर सकेंगे, लेकिन कुछ भी खतरनाक नहीं होगा, और वे अपने दर्ज किए गए डेटा का पूर्वावलोकन करने में सक्षम होंगे और पोस्ट करने से पहले ही किसी भी जांच को सीधा कर देंगे ...


मेरा मानना ​​है कि StackOverflow WMD सिंटैक्स
जॉन

1
StackOverflow वास्तव में WMD का उपयोग करता है। blog.stackoverflow.com/2008/05/… stackoverflow.com/questions/98852/…

WMD सिंटैक्स से आपका क्या अभिप्राय है? जहाँ तक मैं बता सकता हूँ, सभी WMD सिंटैक्स काम करता है। और मुझे अभी तक कुछ भी नहीं मिला है जो काम नहीं करता है ...

2
मार्कडाउन का उपयोग करने में समस्या यह है कि मार्कडाउन HTML को मनमाना अनुमति देता है; तो अपने आप में यह कोई समाधान नहीं है।
जॉर्ज स्टॉकर

7

व्हिटेलिस्टिंग वास्तव में XSS हमलों को रोकने का सबसे अच्छा तरीका है जब उपयोगकर्ताओं को HTML में प्रवेश करने की अनुमति मिलती है, या तो सीधे या रिच टेक्स्ट एडिटर का उपयोग करते हुए।

आपके अन्य सवालों के बारे में:

क्या एक WYSIWYG संपादक है जिसमें मक्खी पर श्वेतसूची की क्षमता शामिल है?

मुझे नहीं लगता कि यह काम कर सकता है। इसके लिए आपको सर्वर साइड कोड की आवश्यकता होती है और क्लाइंट पर आरटीई चलता है।

यदि आप चाहते हैं तो TinyMCE टैग को फ़िल्टर करता है, लेकिन चूंकि यह ब्राउज़र में होता है इसलिए आप इस पर भरोसा नहीं कर सकते। Extended_valid_elements देखें । TinyMCE (मोक्सी) भी सफ़ेद करने का सुझाव देता है, यहाँ देखें ।

क्या मुझे इस बारे में चिंता करनी चाहिए क्योंकि यह केवल 'निजी पोस्टिंग' के लिए होगा

आपको हमेशा HTML को फ़िल्टर करना चाहिए जब तक कि विशिष्ट कारण न हों (बहुत दुर्लभ)। कुछ कारण: ए) कार्यक्षमता जो आंतरिक उपयोगकर्ताओं के लिए है शायद आज कल जनता के लिए है) अनधिकृत पहुंच का प्रभाव कम होगा

उन्हें किसी भी रूप में डेटाबेस में संग्रहीत करने का सबसे अच्छा तरीका है, लेकिन केवल इसे अच्छी तरह से एन्कोडेड और बुरे टैग से छीन लिया गया है?

इस तरह से मैं इसे पसंद करता हूं। मुझे विभिन्न कारणों से डेटाबेस में डालने से पहले उपयोगकर्ता इनपुट को बदलना पसंद नहीं है।


-1

मैं वही काम कर रहा हूं। मैं TinyMCE का उपयोग कर रहा हूं और वर्ड दस्तावेजों से चिपकाने की अनुमति देता हूं। केवल कुछ लोग जो साइट को बनाए रखते हैं वे एक व्यवस्थापक क्षेत्र के माध्यम से ऐसा कर सकते हैं। यह ASP.Net सदस्यता द्वारा सुरक्षित है। जब यह सार्वजनिक साइट पर भेजा जाता है तो मैं HTML.Encode कर रहा हूं।

यदि आप डेटाबेस में रखना चाहते हैं तो आप नीचे दिए गए कोड का उपयोग कर सकते हैं, लेकिन यह सुनिश्चित नहीं करें कि इससे प्रभावित होने वाली दस्तक आपको क्या देगी। आपको अपने श्वेतसूची के साथ जाना पड़ सकता है।

 /// <summary>
    /// Strip HTML
    /// </summary>
    /// <param name="str"></param>
    /// <returns></returns>
    public static string StripHTML(string str)
    {
        //Strips the HTML tags from strHTML 
        System.Text.RegularExpressions.Regex objRegExp = new System.Text.RegularExpressions.Regex("<(.|\n)+?>");

        // Replace all tags with a space, otherwise words either side 
        // of a tag might be concatenated 
        string strOutput = objRegExp.Replace(str, " ");

        // Replace all < and > with < and > 
        strOutput = strOutput.Replace("<", "<");
        strOutput = strOutput.Replace(">", ">");

        return strOutput;
    }

यदि वे <स्क्रिप्ट> अलर्ट ("हेय") </ script> और आप Html.Encode (<स्क्रिप्ट> अलर्ट ("हे") </ script>) जैसे पाठ संग्रहीत करते हैं, तो यह सिर्फ इतना प्रिंट करेगा कि पृष्ठ पर न चले सतर्क
जॉन

मैं एक श्वेतसूची का उपयोग नहीं कर रहा हूं, मैं इसे वैसे ही संग्रहीत कर रहा हूं। उपरोक्त कार्य मदद कर सकता है लेकिन मुझे नहीं पता कि इस पर क्या असर पड़ेगा। यह जानना चाहेंगे कि आप क्या निर्णय लेते हैं। मेरी पोस्ट को नकारात्मक के रूप में चिह्नित क्यों किया गया है?
जॉन

1
मुझे लगता है कि यह है क्योंकि जिस तरह से आपके सॉफ्टवेयर कर रहा है यह एक बहुत भोली कार्यान्वयन है; वहाँ सभी प्रकार की चालें हैं जो आपके कार्यान्वयन के आसपास मिलेंगी।
जॉर्ज स्टॉकर

4
एक श्वेतसूची एक अच्छा विचार है, लेकिन आपकी विधि निश्चित रूप से नहीं है। Regex पाठ में टैग का पता लगाने का एक विश्वसनीय तरीका नहीं है, क्योंकि HTML बहुत अधिक बाधित हो सकती है। किसी लाइब्रेरी जैसे HTML Agility Pack का उपयोग करने के लिए बेहतर है।
नोल्डोरिन

-1

एक विकल्प .NET के लिए HTML एडिट कंट्रोल हो सकता है (जो मैंने लिखा था)।

यह .NET के लिए एक WYSIWYM HTML संपादक है, जो तत्वों को छोड़कर केवल HTML तत्वों के एक सबसेट का समर्थन करता है<script> : तो इस तरह से यह श्वेतसूची के रूप में कार्य करता है।

यदि यह आंतरिक उपयोग (यानी इंट्रानेट साइट) के लिए है, तो नियंत्रण को एक वेब पेज में एम्बेड किया जा सकता है ।

मैंने वर्ड से चिपकाने के लिए समर्थन को एकीकृत नहीं किया है, लेकिन मेरे पास एक घटक है जो उस दिशा में एक कदम है: डॉक टू HTML कनवर्टर ; इसलिए मेरे पास बिल्डिंग ब्लॉक हैं जिनका उपयोग आप ASP.NET में डॉक को HTML में बदलने के लिए कर सकते हैं, संपादक में HTML प्रदर्शित कर सकते हैं, आदि।


-2

जब तक आप सार्वजनिक नहीं होंगे, मेरा IMHO अपने उपयोगकर्ताओं पर भरोसा करता रहेगा।

खैर, अपनी आवश्यकताओं को प्राप्त करने का कोई विश्वसनीय तरीका नहीं है। उदाहरण के लिए कोई भी WYSIWYG संपादक URL (अप्रत्यक्ष उपयोग ट्रैक, अवैध सामग्री) या पाठ (अवैध पाठ, गलत पाठ, छूटा हुआ पाठ) के साथ छवियों को सम्मिलित करने में विफल रहता है।

मेरा नज़रिया यह है कि यदि आप अपने उपयोगकर्ताओं पर भरोसा कर सकते हैं, तो बस सबकुछ अनुमति दें, यदि उपयोगकर्ताओं को पता है कि क्या कम खतरनाक मार्कअप हैं (उन्हें त्रुटियों से बचाए रखने के लिए)।

यदि आपको भरोसा नहीं है, तो विशेष मार्कअप (जैसे मार्कडाउन) का उपयोग करें।

मेरी परियोजना में हम संभावित खतरनाक सामग्री के लिए विशेष प्रकार का उपयोग करते हैं और ऐसी सामग्री को प्रस्तुत करने और स्वीकार करने के लिए विशेष तरीके। इस कोड में हमारे थ्रेड मॉडल में उच्च निशान है और इस पर ध्यान बहुत अधिक है (उदाहरण के लिए प्रत्येक परिवर्तन की समीक्षा दो स्वतंत्र कोडर द्वारा की जानी चाहिए, हमारे पास व्यापक परीक्षण सूट है और इसी तरह)।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.