MCS ક્લાઉડ પ્લેટફોર્મનું સુરક્ષા ઓડિટ

સ્કાયશીપ સાંજ સીરલાઇટ દ્વારા

કોઈપણ સેવાના નિર્માણમાં સુરક્ષા પર સતત કામ કરવું જરૂરી છે. સુરક્ષા એ એક સતત પ્રક્રિયા છે જેમાં ઉત્પાદન સુરક્ષાનું સતત વિશ્લેષણ અને સુધારણા, નબળાઈઓ વિશેના સમાચારોનું નિરીક્ષણ કરવું અને ઘણું બધું શામેલ છે. ઓડિટ સહિત. ઑડિટ ઇન-હાઉસ અને બાહ્ય નિષ્ણાતો દ્વારા કરવામાં આવે છે, જેઓ સુરક્ષામાં ધરમૂળથી મદદ કરી શકે છે કારણ કે તેઓ પ્રોજેક્ટમાં ડૂબેલા નથી અને ખુલ્લા મન ધરાવે છે.

આ લેખ બાહ્ય નિષ્ણાતોના આ સૌથી સરળ દૃષ્ટિકોણ વિશે છે જેમણે Mail.ru ક્લાઉડ સોલ્યુશન્સ (MCS) ટીમને ક્લાઉડ સેવાનું પરીક્ષણ કરવામાં મદદ કરી હતી અને તેમને શું મળ્યું તે વિશે. "બાહ્ય બળ" તરીકે, MCS એ ડિજિટલ સુરક્ષા કંપની પસંદ કરી, જે માહિતી સુરક્ષા વર્તુળોમાં તેની ઉચ્ચ કુશળતા માટે જાણીતી છે. અને આ લેખમાં અમે બાહ્ય ઑડિટના ભાગ રૂપે જોવા મળેલી કેટલીક રસપ્રદ નબળાઈઓનું વિશ્લેષણ કરીશું - જેથી કરીને જ્યારે તમે તમારી પોતાની ક્લાઉડ સેવા બનાવો ત્યારે તમે સમાન રેકને ટાળો.

ઉત્ક્રાંતિ ઉત્પાદન

Mail.ru ક્લાઉડ સોલ્યુશન્સ (MCS) ક્લાઉડમાં વર્ચ્યુઅલ ઈન્ફ્રાસ્ટ્રક્ચર બનાવવા માટેનું પ્લેટફોર્મ છે. તેમાં IaaS, PaaS અને વિકાસકર્તાઓ માટે તૈયાર એપ્લિકેશન છબીઓનું માર્કેટપ્લેસ શામેલ છે. MCS આર્કિટેક્ચરને ધ્યાનમાં લેતા, નીચેના ક્ષેત્રોમાં ઉત્પાદનની સલામતી તપાસવી જરૂરી હતી:

• વર્ચ્યુઅલાઈઝેશન પર્યાવરણના ઈન્ફ્રાસ્ટ્રક્ચરનું રક્ષણ કરવું: હાઈપરવાઈઝર, રૂટીંગ, ફાયરવોલ્સ;
• ગ્રાહકોના વર્ચ્યુઅલ ઈન્ફ્રાસ્ટ્રક્ચરનું રક્ષણ: SDN માં નેટવર્ક, ખાનગી નેટવર્ક સહિત એકબીજાથી અલગતા;
• OpenStack અને તેના ખુલ્લા ઘટકો;
• અમારી પોતાની ડિઝાઇનની S3;
• IAM: રોલ મોડલ સાથે બહુ-ભાડૂત પ્રોજેક્ટ્સ;
• વિઝન (કમ્પ્યુટર વિઝન): છબીઓ સાથે કામ કરતી વખતે API અને નબળાઈઓ;
• વેબ ઈન્ટરફેસ અને ક્લાસિક વેબ હુમલા;
• PaaS ઘટકોની નબળાઈઓ;
• બધા ઘટકોના API.

કદાચ આટલું જ આગળના ઇતિહાસ માટે જરૂરી છે.

કયા પ્રકારનું કાર્ય હાથ ધરવામાં આવ્યું હતું અને તેની શા માટે જરૂર હતી?

સુરક્ષા ઓડિટનો હેતુ નબળાઈઓ અને રૂપરેખાંકન ભૂલોને ઓળખવાનો છે જે વ્યક્તિગત ડેટાના લીકેજ, સંવેદનશીલ માહિતીમાં ફેરફાર અથવા સેવાની ઉપલબ્ધતામાં વિક્ષેપ તરફ દોરી શકે છે.

કાર્ય દરમિયાન, જે સરેરાશ 1-2 મહિના ચાલે છે, ઓડિટર સંભવિત હુમલાખોરોની ક્રિયાઓનું પુનરાવર્તન કરે છે અને પસંદ કરેલી સેવાના ક્લાયંટ અને સર્વર ભાગોમાં નબળાઈઓ શોધે છે. MCS ક્લાઉડ પ્લેટફોર્મના ઓડિટના સંદર્ભમાં, નીચેના ધ્યેયો ઓળખવામાં આવ્યા હતા:

1. સેવામાં પ્રમાણીકરણનું વિશ્લેષણ. આ ઘટકમાં રહેલી નબળાઈઓ અન્ય લોકોના ખાતામાં તરત જ પ્રવેશ મેળવવામાં મદદ કરશે.
2. રોલ મોડલનો અભ્યાસ કરવો અને વિવિધ એકાઉન્ટ્સ વચ્ચે એક્સેસ કંટ્રોલ. હુમલાખોર માટે, કોઈ બીજાના વર્ચ્યુઅલ મશીનની ઍક્સેસ મેળવવાની ક્ષમતા એ ઇચ્છનીય ધ્યેય છે.
3. ગ્રાહક બાજુની નબળાઈઓ. XSS/CSRF/CRLF/વગેરે. શું દૂષિત લિંક્સ દ્વારા અન્ય વપરાશકર્તાઓ પર હુમલો કરવો શક્ય છે?
4. સર્વર બાજુની નબળાઈઓ: RCE અને તમામ પ્રકારના ઈન્જેક્શન (SQL/XXE/SSRF અને તેથી વધુ). સર્વર નબળાઈઓ શોધવામાં સામાન્ય રીતે વધુ મુશ્કેલ હોય છે, પરંતુ તે એકસાથે ઘણા વપરાશકર્તાઓના સમાધાન તરફ દોરી જાય છે.
5. નેટવર્ક સ્તરે વપરાશકર્તા વિભાગના અલગતાનું વિશ્લેષણ. હુમલાખોર માટે, અલગતાનો અભાવ અન્ય વપરાશકર્તાઓ સામે હુમલાની સપાટીને મોટા પ્રમાણમાં વધારે છે.
6. વ્યાપાર તર્ક વિશ્લેષણ. શું વ્યવસાયોને છેતરવું અને મફતમાં વર્ચ્યુઅલ મશીનો બનાવવાનું શક્ય છે?

આ પ્રોજેક્ટમાં, "ગ્રે-બોક્સ" મોડેલ અનુસાર કાર્ય હાથ ધરવામાં આવ્યું હતું: ઑડિટરોએ સામાન્ય વપરાશકર્તાઓના વિશેષાધિકારો સાથે સેવા સાથે ક્રિયાપ્રતિક્રિયા કરી હતી, પરંતુ આંશિક રીતે API નો સ્રોત કોડ ધરાવે છે અને વિકાસકર્તાઓ સાથે વિગતો સ્પષ્ટ કરવાની તક હતી. આ સામાન્ય રીતે સૌથી અનુકૂળ છે, અને તે જ સમયે કાર્યનું એકદમ વાસ્તવિક મોડેલ છે: આંતરિક માહિતી હજી પણ હુમલાખોર દ્વારા એકત્રિત કરી શકાય છે, તે માત્ર સમયની બાબત છે.

નબળાઈઓ મળી

ઓડિટર રેન્ડમ સ્થળોએ વિવિધ પેલોડ (હુમલો કરવા માટે વપરાતો પેલોડ) મોકલવાનું શરૂ કરે તે પહેલાં, વસ્તુઓ કેવી રીતે કાર્ય કરે છે અને કઈ કાર્યક્ષમતા પ્રદાન કરવામાં આવે છે તે સમજવું જરૂરી છે. એવું લાગે છે કે આ એક નકામું કસરત છે, કારણ કે મોટાભાગના અભ્યાસ કરેલા સ્થળોએ કોઈ નબળાઈઓ હશે નહીં. પરંતુ ફક્ત એપ્લિકેશનની રચના અને તેના ઓપરેશનના તર્કને સમજવાથી સૌથી જટિલ હુમલા વેક્ટર શોધવાનું શક્ય બનશે.

તે સ્થાનો શોધવાનું મહત્વપૂર્ણ છે જે શંકાસ્પદ લાગે અથવા કોઈ રીતે અન્ય લોકોથી ખૂબ જ અલગ હોય. અને આ રીતે પ્રથમ ખતરનાક નબળાઈ મળી આવી હતી.

IDOR

IDOR (અસુરક્ષિત ડાયરેક્ટ ઑબ્જેક્ટ રેફરન્સ) નબળાઈઓ એ વ્યાપાર તર્કમાં સૌથી સામાન્ય નબળાઈઓ પૈકીની એક છે, જે એક અથવા બીજાને એવા ઑબ્જેક્ટ્સની ઍક્સેસ મેળવવા માટે પરવાનગી આપે છે કે જ્યાં વાસ્તવમાં ઍક્સેસની પરવાનગી નથી. IDOR નબળાઈઓ વિવિધ સ્તરની જટિલતા ધરાવતા વપરાશકર્તા વિશે માહિતી મેળવવાની શક્યતા ઊભી કરે છે.

IDOR વિકલ્પોમાંનો એક છે આ ઑબ્જેક્ટ્સ માટે એક્સેસ આઇડેન્ટિફાયરની હેરફેર કરીને સિસ્ટમ ઑબ્જેક્ટ્સ (વપરાશકર્તાઓ, બેંક એકાઉન્ટ્સ, શોપિંગ કાર્ટમાંની વસ્તુઓ) સાથે ક્રિયાઓ કરવી. આ સૌથી અણધારી પરિણામો તરફ દોરી જાય છે. ઉદાહરણ તરીકે, ભંડોળ મોકલનારના ખાતાને બદલવાની શક્યતા, જેના દ્વારા તમે તેમને અન્ય વપરાશકર્તાઓ પાસેથી ચોરી કરી શકો છો.

MCS ના કિસ્સામાં, ઓડિટરોએ હમણાં જ બિન-સુરક્ષિત ઓળખકર્તાઓ સાથે સંકળાયેલ IDOR નબળાઈ શોધી કાઢી છે. વપરાશકર્તાના વ્યક્તિગત ખાતામાં, UUID ઓળખકર્તાઓનો ઉપયોગ કોઈપણ ઑબ્જેક્ટને ઍક્સેસ કરવા માટે કરવામાં આવતો હતો, જે લાગતું હતું, જેમ કે સુરક્ષા નિષ્ણાતો કહે છે, પ્રભાવશાળી રીતે અસુરક્ષિત (એટલે ​​​​કે, બ્રુટ ફોર્સ એટેકથી સુરક્ષિત). પરંતુ અમુક સંસ્થાઓ માટે, એવું જાણવા મળ્યું હતું કે નિયમિત અનુમાનિત નંબરોનો ઉપયોગ એપ્લિકેશનના વપરાશકર્તાઓ વિશે માહિતી મેળવવા માટે કરવામાં આવે છે. મને લાગે છે કે તમે અનુમાન લગાવી શકો છો કે એક પછી એક વપરાશકર્તા ID બદલવું, ફરીથી વિનંતી મોકલવી અને આ રીતે ACL (એક્સેસ કંટ્રોલ લિસ્ટ, પ્રક્રિયાઓ અને વપરાશકર્તાઓ માટે ડેટા ઍક્સેસ નિયમો) ને બાયપાસ કરીને માહિતી પ્રાપ્ત કરવી શક્ય છે.

સર્વર સાઇડ રિક્વેસ્ટ ફોર્જરી (SSRF)

ઓપનસોર્સ પ્રોડક્ટ્સ વિશે સારી બાબત એ છે કે તેમની પાસે ઉદ્ભવતી સમસ્યાઓના વિગતવાર તકનીકી વર્ણનો સાથે મોટી સંખ્યામાં ફોરમ છે અને, જો તમે નસીબદાર છો, તો ઉકેલનું વર્ણન. પરંતુ આ સિક્કાની ફ્લિપ બાજુ છે: જાણીતી નબળાઈઓનું પણ વિગતવાર વર્ણન કરવામાં આવ્યું છે. ઉદાહરણ તરીકે, OpenStack ફોરમ પર નબળાઈઓનું અદ્ભુત વર્ણન છે [XSS] и [SSRF], જે અમુક કારણોસર કોઈને ઠીક કરવાની ઉતાવળ નથી.

એપ્લિકેશન્સની સામાન્ય કાર્યક્ષમતા એ સર્વર પર એક લિંક મોકલવાની વપરાશકર્તાની ક્ષમતા છે, જેના પર સર્વર ક્લિક કરે છે (ઉદાહરણ તરીકે, ઉલ્લેખિત સ્રોતમાંથી છબી ડાઉનલોડ કરવા માટે). જો સિક્યોરિટી ટૂલ્સ પોતે લિંક્સને ફિલ્ટર કરતા નથી અથવા સર્વરથી વપરાશકર્તાઓને પરત કરવામાં આવેલા પ્રતિસાદોને ફિલ્ટર કરતા નથી, તો આવી કાર્યક્ષમતા હુમલાખોરો દ્વારા સરળતાથી ઉપયોગમાં લઈ શકાય છે.

SSRF નબળાઈઓ હુમલાના વિકાસને મોટા પ્રમાણમાં આગળ વધારી શકે છે. હુમલાખોર મેળવી શકે છે:

• હુમલો કરાયેલ સ્થાનિક નેટવર્કની મર્યાદિત ઍક્સેસ, ઉદાહરણ તરીકે, ફક્ત અમુક નેટવર્ક સેગમેન્ટ્સ દ્વારા અને ચોક્કસ પ્રોટોકોલનો ઉપયોગ કરીને;
• સ્થાનિક નેટવર્કની સંપૂર્ણ ઍક્સેસ, જો એપ્લિકેશન લેવલથી ટ્રાન્સપોર્ટ લેવલ સુધી ડાઉનગ્રેડ કરવું શક્ય હોય અને પરિણામે, એપ્લિકેશન સ્તર પર સંપૂર્ણ લોડ મેનેજમેન્ટ;
• સર્વર પર સ્થાનિક ફાઇલો વાંચવાની ઍક્સેસ (જો ફાઇલ:/// સ્કીમ સપોર્ટેડ છે);
• અને ઘણું બધું.

ઓપનસ્ટૅકમાં SSRF નબળાઈ લાંબા સમયથી જાણીતી છે, જે પ્રકૃતિમાં "અંધ" છે: જ્યારે તમે સર્વરનો સંપર્ક કરો છો, ત્યારે તમને તેના તરફથી પ્રતિસાદ મળતો નથી, પરંતુ વિનંતીના પરિણામને આધારે તમને વિવિધ પ્રકારની ભૂલો/વિલંબ પ્રાપ્ત થાય છે. . આના આધારે, તમે આંતરિક નેટવર્ક પરના હોસ્ટ્સ પર પોર્ટ સ્કેન કરી શકો છો, જેમાં આવનારા તમામ પરિણામોને ઓછો અંદાજ ન કરવો જોઈએ. ઉદાહરણ તરીકે, ઉત્પાદનમાં બેક-ઓફિસ API હોઈ શકે છે જે ફક્ત કોર્પોરેટ નેટવર્કથી જ ઍક્સેસિબલ છે. દસ્તાવેજીકરણ સાથે (અંદરના વિશે ભૂલશો નહીં), હુમલાખોર આંતરિક પદ્ધતિઓનો ઉપયોગ કરવા માટે SSRF નો ઉપયોગ કરી શકે છે. ઉદાહરણ તરીકે, જો તમે કોઈક રીતે ઉપયોગી URL ની અંદાજિત સૂચિ મેળવવામાં સક્ષમ હતા, તો પછી SSRF નો ઉપયોગ કરીને તમે તેમાંથી પસાર થઈ શકો છો અને વિનંતીનો અમલ કરી શકો છો - પ્રમાણમાં કહીએ તો, એકાઉન્ટમાંથી એકાઉન્ટમાં નાણાં ટ્રાન્સફર કરી શકો છો અથવા મર્યાદા બદલી શકો છો.

OpenStack માં SSRF ની નબળાઈ શોધવાની આ પ્રથમ ઘટના નથી. ભૂતકાળમાં, સીધી લિંક પરથી VM ISO ઈમેજો ડાઉનલોડ કરવાનું શક્ય હતું, જે સમાન પરિણામો તરફ દોરી ગયું. આ સુવિધા હવે OpenStack માંથી દૂર કરવામાં આવી છે. દેખીતી રીતે, સમુદાયે આ સમસ્યાનો સૌથી સરળ અને સૌથી વિશ્વસનીય ઉકેલ ગણ્યો.

અને સાઇન આ HackerOne સેવા (h1) તરફથી સાર્વજનિક રૂપે ઉપલબ્ધ અહેવાલ, ઇન્સ્ટન્સ મેટાડેટા વાંચવાની ક્ષમતા સાથે લાંબા સમય સુધી અંધ SSRFનું શોષણ સમગ્ર Shopify ઇન્ફ્રાસ્ટ્રક્ચરની રૂટ ઍક્સેસ તરફ દોરી જાય છે.

MCS માં, સમાન કાર્યક્ષમતા સાથે બે સ્થળોએ SSRF નબળાઈઓ મળી આવી હતી, પરંતુ ફાયરવોલ અને અન્ય સુરક્ષાને કારણે તેનું શોષણ કરવું લગભગ અશક્ય હતું. એક યા બીજી રીતે, MCS ટીમે સમુદાયની રાહ જોયા વિના કોઈપણ રીતે આ સમસ્યાને ઠીક કરી.

શેલો લોડ કરવાને બદલે XSS

સેંકડો અભ્યાસો લખ્યા હોવા છતાં, વર્ષ પછી વર્ષ XSS (ક્રોસ-સાઇટ સ્ક્રિપ્ટીંગ) હુમલો હજુ પણ સૌથી વધુ છે વારંવાર સામનો કરવો પડ્યો વેબ નબળાઈ (અથવા હુમલો?)

કોઈપણ સુરક્ષા સંશોધક માટે ફાઇલ અપલોડ એ એક પ્રિય સ્થળ છે. તે ઘણીવાર તારણ આપે છે કે તમે મનસ્વી સ્ક્રિપ્ટ લોડ કરી શકો છો (asp/jsp/php) અને OS આદેશો ચલાવી શકો છો, પેન્ટેસ્ટરની પરિભાષામાં - "લોડ શેલ". પરંતુ આવી નબળાઈઓની લોકપ્રિયતા બંને દિશામાં કાર્ય કરે છે: તેમને યાદ રાખવામાં આવે છે અને તેમની સામે ઉપાયો વિકસાવવામાં આવે છે, જેથી તાજેતરમાં "શેલ લોડ" ની સંભાવના શૂન્ય થઈ જાય છે.

હુમલો કરનાર ટીમ (ડિજિટલ સિક્યુરિટી દ્વારા રજૂ કરાયેલ) નસીબદાર હતી. ઓકે, સર્વર બાજુ પર MCS માં ડાઉનલોડ કરેલી ફાઇલોની સામગ્રીઓ તપાસવામાં આવી હતી, ફક્ત છબીઓને મંજૂરી આપવામાં આવી હતી. પરંતુ SVG પણ એક ચિત્ર છે. SVG છબીઓ કેવી રીતે ખતરનાક બની શકે? કારણ કે તમે તેમાં JavaScript સ્નિપેટ્સ એમ્બેડ કરી શકો છો!

તે બહાર આવ્યું છે કે ડાઉનલોડ કરેલી ફાઇલો MCS સેવાના તમામ વપરાશકર્તાઓ માટે ઉપલબ્ધ છે, જેનો અર્થ છે કે અન્ય ક્લાઉડ વપરાશકર્તાઓ, એટલે કે સંચાલકો પર હુમલો કરવો શક્ય છે.

ફિશિંગ લોગિન ફોર્મ પર XSS હુમલાનું ઉદાહરણ

XSS હુમલાના શોષણના ઉદાહરણો:

• જો લોડ કરેલી સ્ક્રિપ્ટ તરત જ સંસાધન API ને એક્સેસ કરી શકે તો શા માટે સત્રને ચોરવાનો પ્રયાસ કરો (ખાસ કરીને હવે માત્ર HTTP-કૂકીઝ સર્વત્ર છે, જે js સ્ક્રિપ્ટનો ઉપયોગ કરીને ચોરીથી સુરક્ષિત છે)? આ કિસ્સામાં, પેલોડ સર્વર ગોઠવણીને બદલવા માટે XHR વિનંતીઓનો ઉપયોગ કરી શકે છે, ઉદાહરણ તરીકે, હુમલાખોરની સાર્વજનિક SSH કી ઉમેરો અને સર્વર પર SSH ઍક્સેસ મેળવો.
• જો CSP નીતિ (સામગ્રી સુરક્ષા નીતિ) JavaScript ને ઇન્જેક્ટ થવાથી પ્રતિબંધિત કરે છે, તો હુમલાખોર તેના વિના પસાર થઈ શકે છે. શુદ્ધ HTML નો ઉપયોગ કરીને, સાઇટ માટે નકલી લૉગિન ફોર્મ બનાવો અને આ અદ્યતન ફિશિંગ દ્વારા એડમિનિસ્ટ્રેટરનો પાસવર્ડ ચોરી લો: વપરાશકર્તા માટેનું ફિશિંગ પૃષ્ઠ સમાન URL પર સમાપ્ત થાય છે, અને વપરાશકર્તા માટે તેને શોધવું વધુ મુશ્કેલ છે.
• છેલ્લે, હુમલાખોર વ્યવસ્થા કરી શકે છે ગ્રાહક DoS - 4 KB કરતા મોટી કૂકીઝ સેટ કરો. વપરાશકર્તાને ફક્ત એક જ વાર લિંક ખોલવાની જરૂર છે, અને જ્યાં સુધી વપરાશકર્તા ખાસ કરીને બ્રાઉઝરને સાફ કરવાનું વિચારે નહીં ત્યાં સુધી સમગ્ર સાઇટ અગમ્ય બની જાય છે: મોટાભાગના કિસ્સાઓમાં, વેબ સર્વર આવા ક્લાયંટને સ્વીકારવાનો ઇનકાર કરશે.

ચાલો અન્ય શોધાયેલ XSS નું ઉદાહરણ જોઈએ, આ વખતે વધુ હોંશિયાર શોષણ સાથે. MCS સેવા તમને ફાયરવોલ સેટિંગ્સને જૂથોમાં જોડવાની મંજૂરી આપે છે. જૂથનું નામ તે હતું જ્યાં XSS મળી આવ્યું હતું. તેની ખાસિયત એ હતી કે વેક્ટર તરત જ ટ્રિગર થયું ન હતું, નિયમોની સૂચિ જોતી વખતે નહીં, પરંતુ જૂથને કાઢી નાખતી વખતે:

એટલે કે, દૃશ્ય નીચે મુજબ બહાર આવ્યું: હુમલાખોર નામમાં "લોડ" સાથે ફાયરવોલ નિયમ બનાવે છે, એડમિનિસ્ટ્રેટર થોડા સમય પછી તેની નોંધ લે છે અને કાઢી નાખવાની પ્રક્રિયા શરૂ કરે છે. અને આ તે છે જ્યાં દૂષિત JS કામ કરે છે.

MCS વિકાસકર્તાઓ માટે, ડાઉનલોડ કરેલ SVG ઈમેજોમાં XSS સામે રક્ષણ આપવા માટે (જો તેને છોડી ન શકાય), તો ડિજિટલ સુરક્ષા ટીમે ભલામણ કરી:

• વપરાશકર્તાઓ દ્વારા અપલોડ કરવામાં આવેલી ફાઇલોને એક અલગ ડોમેન પર મૂકો જેનો "કુકીઝ" સાથે કોઈ સંબંધ નથી. સ્ક્રિપ્ટને એક અલગ ડોમેનના સંદર્ભમાં એક્ઝિક્યુટ કરવામાં આવશે અને તે MCS માટે જોખમ ઊભું કરશે નહીં.
• સર્વરના HTTP પ્રતિસાદમાં, "સામગ્રી-સ્વભાવ: જોડાણ" હેડર મોકલો. પછી ફાઇલો બ્રાઉઝર દ્વારા ડાઉનલોડ કરવામાં આવશે અને ચલાવવામાં આવશે નહીં.

વધુમાં, હવે વિકાસકર્તાઓ પાસે XSS શોષણના જોખમોને ઘટાડવા માટે ઘણી બધી રીતો ઉપલબ્ધ છે:

• "ફક્ત HTTP" ફ્લેગનો ઉપયોગ કરીને, તમે સત્ર "કુકીઝ" હેડરને દૂષિત JavaScript માટે અગમ્ય બનાવી શકો છો;
• CSP નીતિને યોગ્ય રીતે અમલમાં મૂકી હુમલાખોર માટે XSSનું શોષણ કરવાનું વધુ મુશ્કેલ બનાવશે;
• આધુનિક ટેમ્પલેટ એન્જિનો જેમ કે કોણીય અથવા પ્રતિક્રિયા વપરાશકર્તાના ડેટાને વપરાશકર્તાના બ્રાઉઝરમાં આઉટપુટ કરતા પહેલા આપોઆપ સેનિટાઈઝ કરે છે.

દ્વિ-પરિબળ પ્રમાણીકરણ નબળાઈઓ

ખાતાની સુરક્ષા સુધારવા માટે, વપરાશકર્તાઓને હંમેશા 2FA (ટુ-ફેક્ટર ઓથેન્ટિકેશન) સક્ષમ કરવાની સલાહ આપવામાં આવે છે. ખરેખર, જો વપરાશકર્તાના ઓળખપત્રો સાથે ચેડા કરવામાં આવ્યા હોય તો હુમલાખોરને સેવાની ઍક્સેસ મેળવવાથી અટકાવવાની આ એક અસરકારક રીત છે.

પરંતુ શું બીજા પ્રમાણીકરણ પરિબળનો ઉપયોગ હંમેશા ખાતાની સલામતીની ખાતરી આપે છે? 2FA ના અમલીકરણમાં નીચેની સુરક્ષા સમસ્યાઓ છે:

• OTP કોડની બ્રુટ-ફોર્સ સર્ચ (વન-ટાઇમ કોડ્સ). ઓપરેશનની સરળતા હોવા છતાં, મોટી કંપનીઓ દ્વારા OTP બ્રુટ ફોર્સ સામે રક્ષણની અછત જેવી ભૂલોનો પણ સામનો કરવો પડે છે: સ્લેક કેસ, ફેસબુક કેસ.
• નબળા જનરેશન અલ્ગોરિધમ, ઉદાહરણ તરીકે આગામી કોડની આગાહી કરવાની ક્ષમતા.
• તાર્કિક ભૂલો, જેમ કે તમારા ફોન પર કોઈ બીજાના OTPની વિનંતી કરવાની ક્ષમતા, આના જેવી હતી Shopify માંથી.

MCS ના કિસ્સામાં, 2FA ને Google Authenticator અને તેના આધારે લાગુ કરવામાં આવે છે ડ્યૂઓ. પ્રોટોકોલ પોતે જ સમય-ચકાસાયેલ છે, પરંતુ એપ્લિકેશન બાજુ પર કોડ ચકાસણીનો અમલ તપાસવા યોગ્ય છે.

MCS 2FA નો ઉપયોગ ઘણી જગ્યાએ થાય છે:

• વપરાશકર્તાને પ્રમાણિત કરતી વખતે. બ્રુટ ફોર્સ સામે રક્ષણ છે: વપરાશકર્તા પાસે વન-ટાઇમ પાસવર્ડ દાખલ કરવા માટે માત્ર થોડા પ્રયાસો છે, પછી ઇનપુટ થોડા સમય માટે અવરોધિત છે. આ OTP ના બ્રુટ ફોર્સ સિલેક્શનની શક્યતાને અવરોધે છે.
• 2FA કરવા માટે ઑફલાઇન બૅકઅપ કોડ જનરેટ કરતી વખતે, તેમજ તેને અક્ષમ કરતી વખતે. અહીં, કોઈ બ્રુટ ફોર્સ પ્રોટેક્શન લાગુ કરવામાં આવ્યું ન હતું, જેના કારણે જો તમારી પાસે એકાઉન્ટ માટે પાસવર્ડ હોય અને સક્રિય સત્ર હોય, તો બેકઅપ કોડ્સ ફરીથી જનરેટ કરવા અથવા 2FAને સંપૂર્ણપણે અક્ષમ કરવાનું શક્ય બન્યું.

બેકઅપ કોડ્સ OTP એપ્લિકેશન દ્વારા જનરેટ કરેલા સ્ટ્રિંગ મૂલ્યોની સમાન શ્રેણીમાં સ્થિત હતા તે ધ્યાનમાં લેતા, ટૂંકા સમયમાં કોડ શોધવાની તક ઘણી વધારે હતી.

"Burp: Intruder" ટૂલનો ઉપયોગ કરીને 2FAને અક્ષમ કરવા માટે OTP પસંદ કરવાની પ્રક્રિયા

પરિણામ

એકંદરે, MCS એક ઉત્પાદન તરીકે સલામત હોવાનું જણાય છે. ઓડિટ દરમિયાન, પેન્ટેસ્ટિંગ ટીમ ક્લાયન્ટ VM અને તેમના ડેટાની ઍક્સેસ મેળવવામાં અસમર્થ હતી, અને મળી આવેલી નબળાઈઓને MCS ટીમ દ્વારા ઝડપથી સુધારવામાં આવી હતી.

પરંતુ અહીં એ નોંધવું જરૂરી છે કે સુરક્ષા એ સતત કામ છે. સેવાઓ સ્થિર હોતી નથી, તેઓ સતત વિકસતી રહે છે. અને નબળાઈઓ વિના ઉત્પાદનનો સંપૂર્ણ વિકાસ કરવો અશક્ય છે. પરંતુ તમે તેમને સમયસર શોધી શકો છો અને તેમની પુનરાવૃત્તિની શક્યતા ઘટાડી શકો છો.

હવે MCS માં ઉલ્લેખિત તમામ નબળાઈઓ પહેલાથી જ ઠીક કરવામાં આવી છે. અને નવા લોકોની સંખ્યાને ન્યૂનતમ રાખવા અને તેમના જીવનકાળને ઘટાડવા માટે, પ્લેટફોર્મ ટીમ આ કરવાનું ચાલુ રાખે છે:

• બાહ્ય કંપનીઓ દ્વારા નિયમિતપણે ઓડિટ કરો;
• સહયોગ અને વિકાસ ભાગીદારી Mail.ru ગ્રુપ બગ બાઉન્ટી પ્રોગ્રામમાં;
• સુરક્ષામાં જોડાઓ. 🙂

સોર્સ: www.habr.com