2008-10-29 12 views
5

में क्वेरीस्ट्रिंग मानों के साथ सुरक्षा आप कैसे ठीक से सुनिश्चित करते हैं कि उपयोगकर्ता क्वेरीस्ट्रिंग मानों या क्रिया url मानों से छेड़छाड़ नहीं कर रहा है? उदाहरण के लिए, आपके पास अपने टिप्पणी नियंत्रक पर एक हटाएं टिप्पणी कार्रवाई हो सकती है जो एक टिप्पणी आईडी लेता है। आईडी 3 के साथ टिप्पणी हटाने के लिए एक्शन यूआरएल/टिप्पणियां/हटाएं/3 जैसा दिख सकता है।Asp.net एमवीसी

अब स्पष्ट रूप से आप नहीं चाहते कि कोई टिप्पणी 3 को हटाने में सक्षम हो। आम तौर पर टिप्पणी या व्यवस्थापक के मालिक पर ऐसा करने की अनुमति। मैंने देखा कि इस सुरक्षा ने विभिन्न तरीकों को लागू किया है और आप जानना चाहते हैं कि आप में से कुछ इसे कैसे करते हैं।

क्या आप टिप्पणी पुनर्प्राप्त करने के लिए एकाधिक डेटाबेस कॉल करते हैं और जांचते हैं कि टिप्पणी का लेखक उपयोगकर्ता को हटाए गए क्रिया का आह्वान करता है?

क्या आप इसके बजाय टिप्पणी आईडी और उपयोगकर्ता आईडी को संग्रहीत प्रक्रिया में पास करते हैं जो हटाते हैं और हटाते हैं जहां UserID और CommentID पास मानों के बराबर होते हैं?

क्या क्वेरी स्ट्रिंग मान एन्क्रिप्ट करना बेहतर है?

उत्तर

18

आप नहीं करते हैं।

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

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

लॉग इन किए गए उपयोगकर्ता को अनुमतियों का सही सेट सुनिश्चित करने के लिए अतिरिक्त क्वेरी करें। इससे हर किसी के जीवन को इतना आसान बना दिया जाएगा।

0

मेरे द्वारा की गई फैशनेबल चीजों क्वेरी स्ट्रिंग ले, यह सेक, Base64 या सिर्फ हेक्स यह सांकेतिक शब्दों में बदलना है, ताकि "commentid = 4 & userid = 12345" हो जाता है "कोड = 1a2b23de12769"

यह मूल रूप से है "सुरक्षा के माध्यम से अस्पष्टता "लेकिन यह साइट को हैक करने की कोशिश करने वाले किसी के लिए बहुत काम करता है।

0

आप आसानी से ऐसा नहीं कर सकते हैं।

मुझे ऐसी साइट की यादें यादें हैं जो हटाए जाने के लिए कार्रवाई यूआरएल का उपयोग करती हैं।

सभी तब तक अच्छे थे जब तक उन्होंने इंट्रानेट को क्रॉल करने की खोज शुरू नहीं की।

ओउप्स, अलविदा डेटा।

मैं एक समाधान की सिफारिश करता हूं जिससे आप किसी भी चीज के लिए क्वेरीस्ट्रिंग का उपयोग नहीं करते हैं जिसे आप संपादित नहीं करना चाहते हैं।

+0

तो फिर तुम सुझाव है कि मैं संपादित/चीजों को नष्ट फिर? ध्यान रखें कि मैं एएसपीएनटी एमवीसी – Vyrotek

+0

का उपयोग कर रहा हूं, आपको डिलीट करने से पहले अपने कंट्रोलर विधियों पर पोस्ट करना चाहिए - और डिलीट करने से पहले अनुरोध क्रेडेंशियल्स (कुकी/उपयोगकर्ता नाम/पासवर्ड/जो कुछ भी) सत्यापित करना चाहिए। @ शोटाइम की पोस्ट देखें। –

1

आप नीचे दिए गए अनुसार स्वीकृति क्रिया गुण का उपयोग कर नियंत्रक कार्रवाई को हटाने के लिए केवल पोस्ट अनुरोधों को अनुमति भी दे सकते हैं।

[AcceptVerbs(HttpVerbs.Post)] 
public ActionResult Delete(int? id) 
{ 
    //Delete 
} 

तो फिर तुम भी antiforgery निशानी के रूप में यहाँ पर चर्चा इस्तेमाल कर सकते हैं:

http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

+1

एमवीसी 2.0 में आप एचटीपीटी को भी हटा सकते हैं। बस अपनी कार्रवाई पर [HttpPost] के बजाय [HttpDelete] डालें, और फिर पोस्ट के बजाय हटाए गए प्रोटोकॉल का उपयोग करके फॉर्म सबमिट करें। – Josh

3

Vyrotek: इनपुट विधि महत्वपूर्ण नहीं है। प्राप्त करें, पोस्ट करें, एन्क्रिप्टेड/obfuscated प्राप्त करें - कोई वास्तविक अंतर नहीं है।प्रशासनिक कार्रवाई करने के लिए आपके आवेदन को आदेश प्राप्त करने के तरीके से कोई फर्क नहीं पड़ता, यह सुनिश्चित करना होगा कि जारी करने वाले उपयोगकर्ता को वह सामान करने की अनुमति दी जाए जो वह चाहता है। कमांड प्राप्त होने के बाद और इसे निष्पादित होने से पहले अनुमति जांच होनी चाहिए। अन्यथा यह कोई सुरक्षा नहीं है।

6

Enrypting और क्वेरी पैरामीटर decrypting एक छोटी सी प्रक्रिया है और वहाँ कैसे तो एक का उपयोग कर के कुछ महान उदाहरण हैं HttpModule यहाँ StackOverflow पर।

"तुम मत करो", "तुम नहीं कर सकते हैं", या "यह आसान नहीं है" इस दिन और उम्र में बस स्वीकार्य नहीं प्रतिक्रियाओं रहे हैं ...

संबंधित मुद्दे