2011-03-21 19 views
7

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

http://www.mysite.com/?user=boo&password=foo&version=4

मैं अगर वहाँ इस तरह काम करना किसी भी सुरक्षा के मुद्दों होगा सोच रहा था:

मूल रूप से यह एक $_GET अनुरोध, की तरह कुछ है। क्या यह डेटा किसी भी तरह से "अवरुद्ध" हो सकता है?

+0

आप हैश/नमक में देख सकते हैं। यानी, ग्राहक एक हैश किए गए पासवर्ड का उपयोग करने का अनुरोध करते हैं जो कि नमक का उपयोग करके फिर से धोया जाता है केवल आपका सर्वर जानता है। –

+0

यह प्रश्न का प्रकार है जो http://area51.stackexchange.com/proposals/12123/webservice-apis – Cyclone

उत्तर

8

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

इसके बजाय, मैं एक बड़ा प्रमाणीकरण टोकन उत्पन्न करने का सुझाव दूंगा (बड़े आकार की एक यादृच्छिक स्ट्रिंग, 128 वर्ण काम करेंगे)। फिर, उपयोगकर्ता अपने ऐप में "टोकन" इंस्टॉल करेंगे।

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

अब, आपके एप्लिकेशन को यह पाचन टोकन प्राप्त होता है (जिसे $dt कहा जाता है)। फिर, आप इसे पहले से कॉन्फ़िगर किए गए पूर्व-कॉन्फ़िगर किए गए प्रमाणीकरण टोकन के साथ hmac करते हैं।

$authBit = $username . ':' . $authToken; 
$hash = hash_hmac('sha256', $authBit, $digestToken); 
$authField = $username . ':' . $hash . ':' . $digestToken; 

फिर, आप सर्वर पर $authField भेजते हैं।सर्वर तो भागों बंट जाएगा:

list ($user, $hash, $digestToken) = explode(':', $authField); 

अब, आप पहली बार डेटाबेस में उपयोगकर्ता के प्रमाणीकरण टोकन देखने और $authToken में संग्रहीत। फिर, आप यह सुनिश्चित करने के लिए $digestToken देख रहे हैं कि यह मौजूद है और यह 60 सेकंड से भी कम समय पहले बनाया गया था (यदि यह बहुत छोटा है, तो आप इसे समायोजित कर सकते हैं, लेकिन इसे काफी लंबा नहीं बनाते हैं)। किसी भी तरह से, इस बिंदु पर डीबी से इसे हटाएं (इसे पुन: उपयोग करने से रोकने के लिए)।

अब, $digestToken मौजूद है और वैध है, और यदि आप एक $authToken मिल सकता है, तो बस निम्नलिखित जांच:

$stub = $user . ':' . $authToken; 
if ($hash == hash_hmac('sha256', $stub, $digestToken)) { 
    //valid user 
} else { 
    //Not valid 
} 

यह भेजा टोकन प्रत्येक और कभी भी http अनुरोध को बदलने को लाभ मिलता है (अनुरोध स्ट्रीम पढ़ने वाला कोई भी व्यक्ति उस उपयोगकर्ता नाम के अलावा किसी भी संवेदनशील जानकारी को प्राप्त करने में सक्षम नहीं होगा, जिसे आप चाहें तो आगे मास्क कर सकते हैं) ...

-2

अपनी वेबसाइट के यूआरएल को संशोधित और क्लोक करने के लिए .htaccess का उपयोग करें। जैसे: जब यू सफलतापूर्वक .htaccess फाइल बनाने के लिए, दोनों URL एक ही कार्य करेगा

www.mysite.com/cat-1234-foo-5678-index.html 

:

www.mysite.com/index.php?cat=1234&foo=5678 

की तरह लग रही हो जाएगा।

+2

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

+0

यह सिर्फ एक डेमो दोस्त था। आप इच्छित एल्गोरिदम के अनुसार मानों और चर को एन्कोड कर सकते हैं। –

+0

यूआरएल को उदाहरण के लिए भी डिज़ाइन किया जा सकता है: उपरोक्त यूआरएल में http://www.mysite.com/dbu4321gpp8765cheapdata.html –

2

Security trough obscurity काम नहीं करता है, और जीईटी के स्थिर में POST का उपयोग केवल जानकारी को थोड़ा सा कठिन बनाता है यदि आप वास्तव में कंधे पर उपयोगकर्ता को देख रहे हैं।

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

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

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