सुरक्षा संबंधी कमज़ोरी की रिपोर्ट करना
अगर आपको हमारे app, servers या इस वेबसाइट में कोई कमज़ोरी मिली है, तो हम उसके बारे में सुनना चाहते हैं। हमें बताने के लिए हम आपको विरोधी नहीं मानेंगे।
- एक ही पते पर रिपोर्ट करें
- ईमानदार नीयत से किए गए शोध पर कोई कानूनी कार्रवाई नहीं
- 5 कार्यदिवसों में प्राप्ति की पुष्टि
रिपोर्ट करने का तरीका
विषय Security vulnerability के साथ [email protected] पर ईमेल भेजें। आपने क्या पाया, कहाँ पाया और उसे दोबारा कैसे दिखाया जा सकता है, इसके चरणों का विवरण दें। अगर proof of concept मददगार हो, तो उसे शामिल करें; अगर उसमें किसी और का डेटा शामिल है, तो उसे भेजने के बजाय उसका विवरण दें।
हम पाँच कार्यदिवसों के भीतर इसकी प्राप्ति की पुष्टि करने का प्रयास करते हैं। हम आपसे कहते हैं कि इसे सार्वजनिक करने से पहले हमें समस्या ठीक करने के लिए उचित समय दें, और दूसरे लोगों के डेटा तक पहुँचने, सेवा की गुणवत्ता घटाने या ऐसा कोई काम करने से बचें जिससे किसी उपयोगकर्ता को नुकसान पहुँचे।
लागू होने की तारीख
हमारी प्रतिबद्धताएँ
- पाँच कार्यदिवसों के भीतर जवाब, किसी automated reply के बजाय किसी व्यक्ति की ओर से।
- ईमानदार आकलन। अगर हमें लगे कि कोई report vulnerability नहीं है, तो हम बिना चुपचाप बंद किए इसकी वजह बताएँगे। अगर हम सहमत हों, तो हम आपको लगभग बताएँगे कि इसे कब तक ठीक करने की उम्मीद है।
- सद्भावना से की गई research पर कोई कानूनी कार्रवाई नहीं, बशर्ते वह नीचे दिए गए दायरे में हो। इस policy का पालन करने वाले researcher के खिलाफ हम कोई दावा नहीं करेंगे या उसका समर्थन नहीं करेंगे, और किसी report को attack के बजाय contribution मानेंगे।
- अगर आप चाहें तो credit। Fix जारी होने पर हम आपके चुने हुए नाम या handle से आपको acknowledge करेंगे, और अगर आप anonymous रहना चाहें तो आपका नाम नहीं बताएँगे।
- गोपनीयता। आपकी सहमति के बिना हम आपकी पहचान कंपनी के बाहर किसी के साथ साझा नहीं करेंगे, जब तक कि कानूनन ऐसा करना जरूरी न हो।
- हम क्या नहीं दे सकते: paid bug bounty। यह एक छोटी कंपनी है और कोई reward programme नहीं है। हम इसके विपरीत संकेत देने के बजाय साफ-साफ बताना पसंद करेंगे।
दायरा
दायरे में: Telvio के mobile applications, API और वे servers जिनसे ये communicate करते हैं, और यह website। ऐसी कोई भी चीज़ जिसमें किसी user के call records, credit balance या installation identifier उजागर हो सकते हों, किसी और के खर्च पर calls की जा सकें, या call पर दिखने वाला number बदला जा सके, हमारे लिए खास तौर पर महत्वपूर्ण है।
दायरे से बाहर: बिना साबित impact वाले automated scanners की findings; बिना किसी exploitable consequence के missing security headers; ऐसी कोई भी चीज़ जिसके लिए unlocked device तक physical access जरूरी हो; हमारे staff या users की social engineering; denial of service; हमारे द्वारा इस्तेमाल की जाने वाली third-party services की समस्याएँ, जिन्हें सीधे उन्हीं services को report किया जाना चाहिए; और किसी feature की अनुपस्थिति से जुड़ी reports — जैसे कोई rate limit और सख्त हो सकती थी या कोई option हम offer नहीं करते — न कि मौजूद feature में कोई defect।
कृपया इस तरह test न करें जिससे दूसरे लोग प्रभावित हों। ऐसे data को access, modify या delete न करें जो आपका नहीं है, users के लिए service को खराब न करें, यह साबित करने के लिए किसी दूसरे user के खर्च पर calls न करें कि आप ऐसा कर सकते हैं, और automated tooling का इस्तेमाल इतनी मात्रा में न करें जो denial-of-service test जैसा हो। अगर किसी चीज़ को demonstrate करने के लिए आपको account या credit चाहिए, तो पूछें और हम उसका इंतज़ाम करेंगे।
Service यह सीमित कैसे करती है कि breach में क्या उजागर हो सकता है
Consumer service के लिए उपलब्ध सबसे प्रभावी security control यह है कि data को शुरुआत में ही store न किया जाए, और यहाँ मुख्य रूप से यही किया गया है। कोई registration नहीं है, इसलिए कोई user database नहीं है: चुराने के लिए names, email addresses, phone numbers या passwords मौजूद नहीं हैं, और credential stuffing के लिए भी कुछ नहीं है क्योंकि कोई credentials ही नहीं हैं।
Payment पूरी तरह Apple और Google process करते हैं। हमें कभी card number, expiry date, billing address या कोई अन्य payment credential नहीं मिलता — केवल signed receipt identifier मिलता है। हमारे systems compromise होने पर भी कोई payment instrument उजागर नहीं हो सकता, क्योंकि इनमें कुछ store ही नहीं किया जाता।
Call audio कभी record नहीं किया जाता। Call के दौरान यह encrypted form में भेजा जाता है और उसके बाद किसी भी रूप में मौजूद नहीं रहता। Contact lists कभी upload नहीं की जातीं: अगर app को contacts access दिया जाता है, तो number चुनने के लिए list को device पर ही पढ़ा जाता है और वह वहीं रहती है। Precise location कभी collect नहीं की जाती।
जो data मौजूद है, और इसलिए breach में जो उजागर हो सकता है, उसे privacy policy में ईमानदारी से बताया गया है: balance रखने वाला anonymous installation identifier, phone bill में मौजूद तरह के call records, purchase receipt identifiers और IP addresses समेत technical data। Call signalling और audio transit के दौरान encrypted होते हैं, जैसे app और हमारे servers के बीच का पूरा traffic, और call records तक access केवल उन लोगों तक सीमित है जिन्हें service चलाने के लिए इसकी जरूरत है।
ऐसे security सवाल जो vulnerabilities नहीं हैं
तीन बातें नियमित रूप से report की जाती हैं, जबकि वे intended तरीके से काम कर रही हैं। यहाँ उन्हें स्पष्ट कर देने से सभी का समय बचता है।
हर call पर वही number दिखता है। यह जानबूझकर ऐसा रखा गया है, इसके अपने page पर प्रकाशित है, और caller ID की कमजोरी के बिल्कुल उलट है: app में कोई दूसरा number दिखाने का तरीका नहीं है। यही वह property है जो इसे उस impersonation के लिए अनुपयोगी बनाती है जिस पर telephone fraud का अधिकांश हिस्सा निर्भर करता है।
कोई login नहीं है, और यह किसी missing authentication control की बात नहीं है। Authenticate करने के लिए कोई account ही नहीं है। Installation identifier credit balance के लिए bearer token है और उसी तरह treat किया जाता है; device से इसे पढ़ पाने वाला कोई भी व्यक्ति उस balance को खर्च कर सकता है। इसी वजह से यह settings के अलावा कहीं display नहीं होता और device compromise दायरे से बाहर है।
App calls या messages receive नहीं कर सकता। Inbound calls authenticated नहीं हैं, ऐसी report उस capability के बारे में है जो मौजूद ही नहीं है। Inbound path बिल्कुल नहीं है।
एक उपयोगी report में क्या होना चाहिए
इनमें से कुछ भी अनिवार्य नहीं है और इन सभी से बातचीत छोटी हो जाती है। जिस report को हम reproduce कर सकते हैं, उसे fix कर सकते हैं; जिसे reproduce नहीं कर सकते, वह conversation बन जाती है, और conversations सभी के लिए धीमी होती हैं, उस व्यक्ति के लिए भी जिसने समस्या खोजी है।
- यह कहाँ है — app और उसका version, कोई API endpoint या इस website का कोई URL। इन तीनों के अलग-अलग internal owners हैं और यह जानने से report तुरंत सही जगह पहुँच जाती है।
- आपने क्या किया, क्रम से। वही चीज़ देखने के लिए कोई दूसरा व्यक्ति जिन steps को follow करेगा। Requests का sequence सबसे अच्छा है; समस्या के स्वरूप का description भी ठीक है।
- आपने क्या देखा और इसके बजाय क्या उम्मीद की थी। यही हिस्सा finding को scanner की opinion से अलग करता है।
- Attacker इसके साथ क्या कर सकता है। Full exploit chain की demand नहीं — realistic impact के बारे में एक sentence, जिससे तय होता है कि इसे कितनी जल्दी fix किया जाएगा।
- क्या आप credit चाहते हैं, और किस नाम या handle से। आप जो कहेंगे, हम वही इस्तेमाल करेंगे, जिसमें कुछ भी न कहना भी शामिल है।
- दूसरे लोगों का data नहीं। अगर आपकी finding में किसी और के records शामिल हैं, तो उन्हें भेजने के बजाय उनका description दें। हमें वह data नहीं चाहिए और आपको उसे अपने पास नहीं रखना चाहिए।
आपके भेजने के बाद क्या होता है
कोई व्यक्ति इसे पढ़कर पाँच कार्यदिवसों के भीतर, और आम तौर पर उससे पहले, जवाब देता है। पहला जवाब या तो बताता है कि हमने इसे reproduce कर लिया है और लगभग कब तक fix हो जाएगा, या वह एक सवाल पूछता है जिसकी हमें इसे reproduce करने के लिए जरूरत है, या समझाता है कि हमें यह vulnerability क्यों नहीं लगती। हम reports को चुपचाप बंद नहीं करते और न ही automated acknowledgement भेजकर फिर कुछ नहीं करते।
जिस चीज़ का वास्तविक impact हो, उसका fix जारी किया जाता है और हम आपको बताते हैं कि यह हो चुका है। Publication से पहले हम उचित समय माँगते हैं — fix करके release करने के लिए पर्याप्त समय, जिसमें mobile app के लिए हमारे नियंत्रण से बाहर App Store या Google Play review cycle भी शामिल है — और अगर इसमें सामान्य से अधिक समय लगने वाला हो, तो हम आपको ईमानदारी से बताएँगे, बजाय इसके कि कोई deadline चुपचाप गुजर जाए।
अगर हम आपसे असहमत हों, तो हम ऐसा कहेंगे और वजह भी बताएँगे, और आप उस असहमति को publish करने के लिए स्वतंत्र हैं। ऐसी disclosure policy जो केवल तभी काम करे जब researcher vendor से सहमत हो, policy नहीं है।
सारांश
विषय में “Security vulnerability” लिखकर [email protected] पर ईमेल करें। आपने क्या पाया और उसे दोबारा कैसे दिखाया जा सकता है, यह बताएं। पाँच कार्यदिवसों के भीतर किसी व्यक्ति की ओर से पुष्टि मिलेगी।
ऊपर बताए दायरे में सद्भावना से की गई रिसर्च पर कानूनी कार्रवाई नहीं की जाएगी, और अगर आप चाहें तो हम आपको श्रेय देंगे। कोई paid bounty नहीं है, और हम इसके उलट संकेत देने के बजाय यह साफ़ कहना पसंद करेंगे।
यह service बहुत कम जानकारी रखने के लिए बनाई गई है: कोई account नहीं, कोई password नहीं, payment details नहीं, call recordings नहीं, contact lists नहीं और location नहीं। यही security control ज़्यादातर काम करता है।
अक्सर पूछे जाने वाले प्रश्न
मैं Telvio को security vulnerability की रिपोर्ट कैसे करूँ?
[email protected] पर ईमेल भेजें और subject में Security vulnerability लिखें। आपने क्या पाया, वह कहाँ है और उसे दोबारा reproduce करने के steps बताएं। हम पाँच working days के भीतर इसकी पुष्टि करने की कोशिश करते हैं और issue publish करने से पहले उसे ठीक करने के लिए उचित समय माँगते हैं।
क्या Telvio का bug bounty programme है?
नहीं। कोई paid reward programme नहीं है। हम किसी व्यक्ति की ओर से acknowledgement, ईमानदार assessment, आपकी इच्छा होने पर credit और scope के भीतर good-faith research के लिए कोई legal action न लेने की प्रतिबद्धता देते हैं।
क्या Telvio किसी security researcher के खिलाफ legal action लेगा?
Published scope के भीतर की गई good-faith research के लिए नहीं। जो researcher इस policy का पालन करता है और दूसरे लोगों के data को access करने या service को खराब करने से बचता है, उसके खिलाफ हम कोई claim pursue या support नहीं करेंगे।
Telvio के systems में breach होने पर क्या उजागर हो सकता है?
एक anonymous installation identifier, जिसमें credit balance होता है; phone bill में दर्ज होने वाले प्रकार के call records; purchase receipt identifiers; और IP addresses सहित technical data। ऐसे कोई names, email addresses, phone numbers, passwords, payment details, call recordings, contact lists या location data मौजूद नहीं हैं, जिन्हें उजागर किया जा सके।
क्या Telvio calls encrypted होती हैं?
Call signalling और audio transit के दौरान encrypted होते हैं, और app व servers के बीच का पूरा traffic भी। किसी ordinary telephone number पर की गई call का अंतिम हिस्सा traditional telephone network के ज़रिए जाता है, जो app के control से बाहर है और end to end encrypted नहीं होता — real phone पर dial करने वाली हर service में यही बात लागू होती है।
Telvio में password क्यों नहीं है?
क्योंकि इसमें कोई account नहीं है। कुछ भी register नहीं किया जाता, इसलिए protect करने के लिए कोई credential नहीं है और credential stuffing से attack करने के लिए भी कुछ नहीं है। Installation identifier credit balance के लिए bearer token की तरह काम करता है, इसलिए device compromise को out of scope माना जाता है।
किसी vulnerability को publish करने से पहले मुझे कितने समय तक इंतज़ार करना चाहिए?
इतना समय कि fix तैयार करके release किया जा सके। Mobile app के मामले में इसमें app store review cycle भी शामिल है, जिसे हम control नहीं करते। हम अपने पहले reply में expected timeline बताएँगे और अगर इसमें देरी होती है तो आपको ईमानदारी से बताएँगे, बजाय इसके कि बिना कुछ कहे deadline निकल जाने दें।
क्या reported issue ठीक होने पर Telvio मुझे बताएगा?
हाँ। हम reports को चुपचाप close नहीं करते। पहला reply या तो यह confirm करता है कि हमने issue reproduce कर लिया है और rough timeline बताता है, या उसे reproduce करने के लिए ज़रूरी एक सवाल पूछता है, या समझाता है कि हम इसे vulnerability क्यों नहीं मानते।
