એડબ્લોક પ્લસ યાદીઓમાં નબળાઈ દૂષિત કોડને ચલાવવા દે છે

તાજેતરમાં એક નબળાઈ મળી આવી છે જે જાળવણીકારોને ફિલ્ટર સૂચિઓને અવરોધિત કરવાની મંજૂરી આપી શકે છે એડબ્લોક પ્લસ, એડબ્લોક અને યુબ્લોકર બ્રાઉઝર એક્સ્ટેંશન માટે ફિલ્ટર્સ બનાવવા માટે કે જે વેબસાઇટ્સમાં રીમોટ સ્ક્રિપ્ટોને ઇન્જેકટ કરે.

એક વપરાશકર્તા આધાર સાથે જેણે 10 મિલિયનનો આંકડો પાર કર્યો છે, જો દૂષિત સ્ક્રિપ્ટોને એડ બ્લocકર્સમાં ઇન્જેક્ટ કરવામાં આવી હોય, તો આ નોંધપાત્ર અસર કરશે કારણ કે તેઓ અનિચ્છનીય પ્રવૃત્તિઓ કરી શકે છે, જેમ કે કૂકીઝની ચોરી, કનેક્શનની માહિતી, પૃષ્ઠ રીડાયરેક્ટ્સ અથવા અન્ય અનિચ્છનીય વર્તનનું કારણ.

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

સામાન્ય રીતે, તેઓ લોકોની એક નાની ટીમ અથવા એક જ વ્યક્તિ દ્વારા ચલાવવામાં આવે છે.

જ્યારે આ સૂચિઓ એડબ્લોક પ્લસ જેવા જાહેરાત અવરોધિત એક્સ્ટેંશનથી લોડ કરવામાં આવે છે, ત્યારે આ એક્સ્ટેંશન બ્રાઉઝરને સૂચિમાં મૂકેલા URL સાથે કનેક્ટ થવામાં અટકાવશે અને આમ આ દૂષિત જાહેરાતો અથવા સ્ક્રિપ્ટ્સ સાથે જોડાણને અટકાવે છે.

$ ફરીથી લખો ફિલ્ટર વિકલ્પ સમસ્યા પેદા કરી રહ્યું છે

જ્યારે એડબ્લોકર પ્લસ 3.2 2018 માં શરૂ થયું, તે નવું ફિલ્ટર સૂચિ વિકલ્પ ઉમેર્યો, જેને called ફરીથી લખો.

આ વિકલ્પ માન્ય સૂચિ સંભાળનારને વેબ વિનંતીને બદલો જે નિયમિત અભિવ્યક્તિ સાથે મેળ ખાય છે ખાસ કરીને બીજા URL સાથે.

હ્યુબર્ટ ફિગ્યુઅરે, જેણે આ કાર્ય રજૂ કર્યું, સમજાવી કે:

"ક્રોમ, ફાયરફોક્સ અને raપેરા (અને 3.2 ના વિકાસ સંસ્કરણ) માટે એડબ્લોક પ્લસ 3.1.0.2053.૨ હોવાથી, એક નવું ફિલ્ટર વિકલ્પ w ફરીથી લખવું તમને તેને અવરોધિત કરવાને બદલે સંસાધનનો URL ફરીથી લખી શકે છે.

જ્યારે એડબ્લોક પ્લસ $ ફરીથી લખવા વિકલ્પ સાથે ફિલ્ટરને વિનંતી URL ને સોંપે છે, ત્યારે તે પ્રદાન કરેલા નિયમના આધારે URL ને પરિવર્તિત કરે છે અને બ્રાઉઝરને તે જ સમયે સંસાધન લોડ કરવાનું કહે છે.

$ નિયમનો વાક્યરચના ફરીથી લખાઈ એક સ્ટ્રિંગને નિર્દિષ્ટ કરે છે જે નવા URL માટે નમૂના તરીકે સેવા આપે છે.

filter n ફિલ્ટરની નિયમિત અભિવ્યક્તિ n-th ઉપ-મેચ દ્વારા બદલવામાં આવે છે. આ જાવાસ્ક્રિપ્ટ સ્ટ્રિંગ.પ્રોટોટાઇપ.રેપ્લેસ () ફંક્શન જેવું જ વાક્યરચના છે.

જો પરિણામી URL સંબંધિત છે (એટલે ​​કે તમારી પાસે યજમાન નથી), મૂળ ક્વેરીના મૂળનો ઉપયોગ આધાર તરીકે કરવામાં આવશે. બંને કિસ્સામાં, જો નવું URL મૂળ શેર કરતું નથી, તો પુનર્લેખન અસફળ માનવામાં આવશે અને પ્રારંભિક વિનંતિ પસાર થશે.

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

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

ગૂગલ મેપ્સ પર પણ કોડ એક્ઝેક્યુશન કરવામાં આવે છે

સુરક્ષા સંશોધનકારે સમજાવ્યું કે:

અમુક શરતો હેઠળ, અનધિકૃત દૂષિત ફિલ્ટર જાળવણીકાર માટે કોઈ નિયમ બનાવવો શક્ય છે કે જે કોઈ ચોક્કસ સાઇટમાં રીમોટ સ્ક્રિપ્ટને ઇન્જેક્ટેટ કરે.

આ કરવા માટે, ફક્ત તે સાઇટ માટે જુઓ જે સ્ક્રિપ્ટો લોડ કરે કોઈપણ ડોમેન કે જેમાં ખુલ્લા રીડાયરેક્ટ હોય છે અને XMLHttpRequest અથવા મેળવોનો ઉપયોગ કરો ચલાવવા માટે સ્ક્રિપ્ટો ડાઉનલોડ કરવા.

તે શોધવું ખૂબ મુશ્કેલ નથી, કારણ કે એકલા આવું કરવા માટે ખ્યાલના પુરાવા તરીકે ફક્ત ગૂગલ મેપ્સનો ઉપયોગ કરો.

સંશોધનકારે તે સમજાવ્યું નીચેના માપદંડોને પૂર્ણ કરવો આવશ્યક છે જેથી આ પદ્ધતિથી વેબ સેવાનો ઉપયોગ કરી શકાય:

• પૃષ્ઠે XMLHttpRequest અથવા આનયન વાપરીને JS શબ્દ લોડ કરવો આવશ્યક છે અને વળતર કોડ ચલાવો.
• પૃષ્ઠમાં તે સ્રોતોને પ્રતિબંધિત કરવા જોઈએ નહીં કે જેનાથી તે સામગ્રી સુરક્ષા નીતિ દિશાનિર્દેશોનો ઉપયોગ કરીને ફરીથી મેળવી શકાય છે, અથવા ડાઉનલોડ કરેલા કોડને ચલાવવા પહેલાં અંતિમ વિનંતી URL ને માન્ય કરે છે.
• પુન codeપ્રાપ્ત કોડના સ્રોતમાં હોસ્ટ તરફથી ખુલ્લી સર્વર-સાઇડ રીડાયરેક્ટ અથવા મનસ્વી વપરાશકર્તા સામગ્રી હોવી આવશ્યક છે.

સ્ક્રિપ્ટોને ડાઉનલોડ કરવા અને પુનirectદિશામાન ખોલવા માટે XMLHttpRequest અથવા આનયનનો ઉપયોગ કરવો એ સમસ્યાની બે કી છે.

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