2009-05-11 7 views
9

मैं अपने आईफोन ऐप के लिए एक बहुत ही सरल वेब सेवा लिख ​​रहा हूं। मान लें कि यह एक http पृष्ठ है जो http://mysite/getRand पर एक यादृच्छिक संख्या देता है। मैं कैसे सुनिश्चित करूं कि यह पृष्ठ केवल मेरे आईफोन ऐप से ही पहुंचा जा सकता है, न कि अन्य ग्राहकों से? मैंने कुछ सरल पासवर्ड तंत्र करने का विचार किया है, लेकिन यह कि मेरे ऐप को क्या भेजता है उसे कैप्चर करके आसानी से स्नीफ किया जा सकता है।केवल मेरे कोड से मेरी वेब सेवा तक पहुंच सुनिश्चित कैसे करें?

इसका कारण केवल वैध अनुरोधों को अनुमति देकर मेरे सर्वर के भार को कम करना है।

उत्तर

0

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

यदि आप रेल पर रूबी का उपयोग नहीं कर रहे हैं, तो कोड प्रमाणीकरण की विधि आपके द्वारा उपयोग की जाने वाली किसी भी तकनीक में अनुसंधान और कार्यान्वित करने के लिए एक अच्छा हो सकता है।

Rails Security Guide, विशेष रूप से सेक्शन 3.1 (सीएसआरएफ काउंटरमेजर्स) पर एक नज़र डालें।

0

आप आईफोन से वर्तमान समय और आईपी पते एन्क्रिप्ट करने जैसे कुछ कर सकते हैं, और उसके बाद इसे सर्वर पर डिक्रिप्ट कर सकते हैं। नकारात्मकता यह है कि आपको "गुप्त" कुंजी जानने के लिए आईफोन ऐप की आवश्यकता है ताकि केवल यह वैध पहुंच टोकन उत्पन्न कर सके ... और एक बार जब जंगली जंगली हो जाए, तो यह केवल हैक होने से पहले ही समय की बात होगी ऐप वास्तव में प्रयास के लायक है।

आप एप्लिकेशन के कुछ यादृच्छिक भाग का उपयोग करके प्रतिक्रिया को एन्क्रिप्ट कर सकते हैं जिसका उपयोग करने के लिए इसका मतलब है, प्रतिक्रिया के एक अनएन्क्रिप्टेड बिट में बाइनरी का स्थान निर्दिष्ट करना। फिर कम से कम केवल आपके बाइनरी तक पहुंच वाले क्लाइंट इसे डिक्रिप्ट करने में सक्षम होंगे ... लेकिन फिर, यह शायद 100% सुरक्षित है।

आखिरकार आपको खुद से पूछना होगा कि सेवा को सुरक्षित करने के लिए आप कितना प्रयास करना चाहते हैं, यह है कि आपको लगता है कि हैकर्स इसका कितना प्रयास करेंगे।

0

मैं कोको टच डेवलपर नहीं हूं, लेकिन मुझे लगता है कि एसएसएल पर HTTP प्रमाणीकरण लागू करना आसान होगा और शायद यह वही है जो आप खोज रहे हैं।

आपको केवल सर्वर पक्ष पर HTTP प्रमाणीकरण सेटअप करना है (आपने सर्वर पक्ष पर जो भी उपयोग कर रहे हैं उसका उल्लेख नहीं किया है) और अपने वेबसर्वर पर एक स्व-हस्ताक्षरित SSL प्रमाणपत्र बनाएं। किया हुआ। :)

हमें अपने सेटअप के बारे में और बताएं और हम आपकी सहायता करने में सक्षम होंगे।

+0

कैसे है कि सेवा तक पहुंचने से HTTPS का उपयोग करके किसी अन्य अनुप्रयोग रोक रहा है? हां, हैकर को प्रमाणीकरण विवरण का उपयोग करने की आवश्यकता होगी, लेकिन अगर हम एक संसाधन हैकर मानते हैं, तो मुझे नहीं लगता कि यह उन्हें रोक देगा। –

+0

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

11

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

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

इस धागे में अधिकांश विचार इस हमले के लिए कमजोर हैं।

यह कहा गया है कि, आपके आवेदन को अलग करने के लिए पर्याप्त देखभाल करने वाले किसी व्यक्ति की संभावना शायद काफी दूर है।

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

जाहिर है, आपको एसएसएल पर अनुरोध करना चाहिए अन्यथा हमलावर यातायात को तोड़ सकता है।

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

+1

सहमत हुए। सभी सुरक्षा की तरह, यह चाल सेवा गरीबों तक पहुंचने के लिए लागत का लाभ उठाना है। –

1

मैं क्लाइंट-साइड कुंजी के साथ https प्रोटोकॉल का भी उपयोग करूंगा। आप सभी के लिए एक क्लाइंट कुंजी का उपयोग कर सकते हैं या आप प्रत्येक क्लाइंट के लिए एक अलग कुंजी भी उत्पन्न कर सकते हैं और अपने सर्वर पर "पंजीकरण" कर सकते हैं।

मुझे लगता है कि यह छोटी परियोजना के लिए बहुत काम है, लेकिन अगर आपको प्रमाणीकरण की आवश्यकता है तो यह उचित काम की तरह लगता है।

आपको यह जांचना चाहिए कि मोबाइल फोन के मालिक द्वारा आसानी से नहीं देखा जाता है। और याद रखें कि कोई भी किसी भी मामले में इसे हैक करने में सक्षम होगा।

1

मुझे लगता है कि आप एसएसएल का उपयोग नहीं करना चाहते हैं? यदि आप करते हैं तो आप HTTPS सत्र खोल सकते हैं और फिर अनुरोध में कुछ गुप्त कुंजी पास कर सकते हैं।

आप SSL अपने विकल्पों को सीमित हैं नहीं चाहते हैं: छद्म सुरक्षा मैं दोनों प्रमाणीकरण और प्राधिकरण के तरीकों का सुझाव और एक तिहाई के लिए समग्र यातायात को कम करने के लिए:

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

प्रमाणीकरण: बेशक आप नकली अनुप्रयोगों को भी लॉक करना चाहते हैं। यहां साइट के साथ प्राधिकरण तंत्र होना सर्वोत्तम होगा। जब तक क्लाइंट लॉग इन नहीं करता है तब तक कीफाइल को प्रतिस्थापित न करें। उपयोगकर्ताओं को कुंजी फाइल ट्रैक करें। आदि

यातायात में कमी: आप यातायात के अश्लील राशि प्राप्त कर रहे हैं या यदि आपको संदेह किसी डॉस के लिए अपने सर्वर की कोशिश कर रहा है, तो आप भी दोनों सर्वर हो सकता है और ग्राहकों को एक procedurally उत्पन्न यूआरएल पर/प्रतिक्रिया अनुरोध करने के लिए सिंक कर सकते हैं कि अक्सर बदलें। अगर कोई आपको अनुरोध के साथ बाढ़ कर रहा है तो इतने सारे HTTPS सत्र खोलना/बंद करना अपर्याप्त है।

2

साइमन के विचार पर अनुवर्ती करने के लिए, आप अपने आवेदन में एक महत्वपूर्ण स्ट्रिंग आसानी से प्राप्त कर सकते हैं, फिर डिवाइस आईडी भेज सकते हैं, और उसके बाद डिवाइस आईडी XOR'ed (या स्ट्रिंग एन्क्रिप्शन के लिए कुछ अन्य सरल एल्गोरिदम) अपनी कुंजी स्ट्रिंग के साथ ।

चूंकि आप उपयोग करने के लिए महत्वपूर्ण मूल्य जानते हैं, इसलिए यह स्ट्रिंग अलग-अलग तरफ इस स्ट्रिंग को "डिक्रिप्ट" करने के लिए तुच्छ है और सत्यापित करें कि मान मेल खाते हैं।

इस तरह, पासवर्ड प्रत्येक उपयोगकर्ता के डिवाइस के लिए अलग होता है, और "कुंजी" स्ट्रिंग को कभी भी अनचाहे इंटर्नसेट के तारों पर नहीं भेजा जाता है। :-)

हां, यह पता लगाने के लिए असंभव नहीं होगा, लेकिन दूसरों की तरह कहा है, विचार यह असंभव नहीं है। विचार यह है कि यह लायक है इससे ज्यादा परेशानी है।

0

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

ऐसा करने का एक और सुझाव, सर्वर पर random seed से यादृच्छिक संख्याएं उत्पन्न करना है और ग्राहक। सर्वर को ट्रैक करने की आवश्यकता होगी कि सभी क्लाइंट यादृच्छिक संख्याओं के क्रम में कहां हैं, और क्लाइंट द्वारा भेजे गए नंबर पर उस नंबर से मेल खाते हैं।

ग्राहक भी सर्वर तक पहुँच दी जानी रजिस्टर करना होगा। यह एक प्रमाणीकरण तंत्र के रूप में भी काम करेगा।

तो:

//Client code: 
$sequence = file_get_contents('sequence.txt'); 
$seed = file_get_contents('seed.txt'); 
$sequence++; 

//Generate the $sequence-th random number 
srand($seed); 
for ($i = 0; $i <= $sequence; $i++) { 
    $num = rand(); 
} 
//custom fetch function 
get_info($main_url . '?num=' . $num . '&id' = $my_id); 

यह इस के लिए एक अनुरोध समान उत्पन्न करेगा:

http://webservice.com/get_info.php?num=3489347&id=3

//Server Code: (I'm used to PHP) 

//Get the ID and the random number 
$id = (int)$_REQUEST['id']; 
$rand = (int)$_REQUEST['num']; 
$stmt = $db->prepare('SELECT `sequence`, `seed` FROM `client_list` WHERE `id` = :id'); 
if ($stmt->execute(array(':id' => $id)) { 
    list($sequence, $seed) = $stmt->fetch(PDO::FETCH_ASSOC); 
} 
$sequence++; 

//Generate the $sequence-th random number 
srand($seed); 
for ($i = 0; $i <= $sequence; $i++) { 
    $num = rand(); 
} 
if ($num == $rand) { 
    //Allow Access 
} else { 
    //Deny Access 
} 

प्रत्येक ग्राहक के लिए आ विभिन्न बीज का उपयोग करके आप यह सुनिश्चित करें कि हैकर्स नहीं कर सकते भविष्यवाणी की गई पिछली संख्याओं को ट्रैक करके एक यादृच्छिक संख्या भविष्यवाणी करें। यदि आपके ऐप को अनुरोधों के साथ डिवाइस आईडी भेजने -

1

यहाँ एक सोचा नहीं है।

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

उन लोगों के लिए जो वास्तव में अन्य ऐप्स (आपके नहीं) से असली डिवाइस आईडी भेजते हैं, आप यह देखने के लिए उपयोग रुझानों की निगरानी कर सकते हैं कि कॉल आपके ऐप के प्रदर्शन के तरीके से मेल खाते हैं या नहीं - जैसे किसी डिवाइस द्वारा एक कॉल का उपयोग किया जा रहा है प्रारंभिक कॉल जिसे आप आम तौर पर उम्मीद करेंगे, और इसी तरह - उनको भी अवरुद्ध करें।

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

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