Clickjacking جديد الأخطر على متصفحات الأنترنت

لم أفهم الفكرة بشكل محدد، أعتقد أني سأقوم بقراءة المقال الأصلي لأحاول استيضاح بعض النقاط.

سلمت يداك.

Xacker كتب:

لم أفهم الفكرة بشكل محدد، أعتقد أني سأقوم بقراءة المقال الأصلي لأحاول استيضاح بعض النقاط.

سلمت يداك.

لست من مستعملي FireFox لكن حسب ما فهمت الإضافة NoScript تقوم فقط بتعطيل JavaScript

في متصفح Opera لست بحاجة لاضافة لفعل هذا لانه متوفر في الخيارات

من

tools -> preferences -> advanced -> content

تعطيل الخيار enable Java Script

او بمجرد الضغط على المفتاح F12 وعطل ما تريد :lol:

B.M.AbdelAziZ كتب:

في متصفح Opera لست بحاجة لاضافة لفعل هذا لانه متوفر في الخيارات

من

tools -> preferences -> advanced -> content

تعطيل الخيار enable Java Script

هذا متاح في فايرفوكس أيضا:

Tools -> Options -> Content

تفعيل/إزالة خيار Enable JavaScript

Xacker كتب:

لم أفهم الفكرة بشكل محدد، أعتقد أني سأقوم بقراءة المقال الأصلي لأحاول استيضاح بعض النقاط.

سلمت يداك.

لم أرد أول الأمر لأني أثق في مقدرتك على البحث و أنتظر خلاصة ما تجده

@eramax نفس الملاحظة أيضا لمشاركة اخونا xacker:

لم تذكروا أماكن الغموض لأن التعبير من المغرب العربي يختلف عنه في المشرق، و كثيرا لا أفهم بعض التعابير (باللغة العربية) و أحتاج لأيام حتى أصادف المعني

B.M.AbdelAziZ كتب:

لست من مستعملي FireFox لكن حسب ما فهمت الإضافة NoScript تقوم فقط بتعطيل JavaScript

في متصفح Opera لست بحاجة لاضافة لفعل هذا لانه متوفر في الخيارات

من

tools -> preferences -> advanced -> content

تعطيل الخيار enable Java Script

او بمجرد الضغط على المفتاح F12 وعطل ما تريد :lol:

لقد ذكرت javascript للتأكيد عليها و لم أحب التعمق في مزاياها و تركتها ليتفاجأ مستعملها لمدى التحكم الذي تعطيه له باستخدامها مع FF

حتى IE لديه هذه الخصائص و يمكنك حتى من تعطيل بعض أعمال net framework

لكن الكلام هو كلام خبير و معتمد من طرف الشركات الكبرى و لو كان Opera أو غيره يملك خاصية دفاع اكثر كفاءة أو تقوم بالمطلوب لذكرها

حتى FF لديه خاصية تعطيل javascript

يخصوص NOScript ليست فقط للـ javascript إنها أيضا تعطل ملفات الفلاش و أخرى مع ترك الخيار للتفعيل

مع العلم أن OWASP نصف مغلق لخطورة المعلومات المكشوفة فيه و صعب جدا تعرف تفاصيل حتى من طرف المكتشفين أنفسهم

:)

بعد كتابة ردي السابق راجعت موقعها http://noscript.net/

تقوم بتعطيل Java/JavaScipt/Flashوالاضافات لاي موقع غير موثوق

اي المستخدم يقوم بادخال المواقع الموثوقو بقائمة

بحثت فوجدت طريقة تنفع مع كل المتصفحات باستخدام Proxomitron

http://prxbx.com/forums/showthread.php?tid=970

merouane كتب:

لا أظن أن Opera أو IE يستطيعان التغلب على هذه المشكلة بما يتوفران عليه حالي

الامور ليست بالظن...

مشكور

أخي الكريم على هذه المعلزمات القيمة وتابع نهجك هذا :wink:

هنا للمزيد عن الموضوع

http://www.freedom-to-tinker.com/blog/wzel...forgery-attacks

للتوضيح أخي مروان عندما قلت أني لم أفهم الفكرة من الموضوع بشكل كاف قصدت أني لم أفهم ما هو مقدار ومقياس الخطر الذي نتكلم عنه. بعد مراجعة الروابط وتفقد الموضوع بشكل أكبر فهمت الفكرة التي كان المقال يحاول إيصالها.

لكن كتعليق بسيط على هذا الموضوع من الناحية الأمنية، القلق من الـ Javascript كلغة برمجة تستطيع في بيئة عمل معينة (نطاق الصفحة التي تعمل بها والصلاحيات التي يمكن الحصول عليها من خلالها لو تم استغلالها بشكل خاطئ) أن تشكل خطراً على بيانات المستثمر فهو أمر قديم, وشئ لا يمكن فعلياً بشكل كامل إيقافه أو التخلص منه, ولشخص غير خبير في النواحي الأمنية أو ليس بمطور ويب أو حتى مبرمج على الأقل، سيكون الخطر غامض عليه ولا يدركه فعلياً.

لنعود قليلاً إلى الموضوع ومسألة الـ clickjacking، هناك أحداث كثيرة Events التي يمكن استخدامها ضمن صفحة الويب والتي قد يتم استغلالها بشكل سئ, أحداث مثل onLoad و onChange و onMouseOver أو onMouseOut يمكن استغلالها أبشع استغلال في صفحة تسمح بـ جافاسكربت لكن في الوقت نفسه علينا أن نطرح أنفسنا السؤال، هل يمكن الاستغناء عن جافاسكربت في أي صفحة ويب هذه الأيام؟ والجواب بشكل 99.0% لا، لا يمكن هذا.

طيب الخطر كبير في هذه الحالة؟ ليس كثيراً في الواقع..

جافا سكربت تصبح غير آمنة في بيئة عمل غير آمنة للمستخدم، بمعنى، موقع ملئ بالثغرات الأمنية مثل CrossSite Scripting المسماة XSS أو Session-hijacking أو Cookie-hijacking الخ من هذه الثغرات الأمنية في بنية عمل الصفحة نفسها ناهيك عن الثغرات التي يمكن أن تظهر من خلال عدم فحص المتغيرات الآتية من ناحية العميل وليس من ناحية السيرفر كاسم المستخدم أو كلمة المرور أو التعليق على خبر ما.. هذه تخلق مشاكل أمنية توفر بيئة عمل غير آمنة يمكن حينها لشخص ما أن يستغلها في أن يقوم بحقن سكربتات ضارة في الصفحة أو الموقع بكامله وحينها يظهر خطر Clickjacking برأيي.. أي Clickjacking غير موجودة في غياب بقية الثغرات الأمنية التي يكون سببها الأول والأخير هو المبرمج أو المطور نفسه.

والأمر مشابه لأي لغة برمجة أخرى، الاستخدام غير الصحيح لأي وظيفة ما في لغة برمجة ما قد توفر بيئة غير آمنة يمكن استغلالها في تمرير شئ خطير لكن هذا الخطر يصبح معدوم في حالة الاستخدام الصحيح لوظيفة ما حتى لو كانت هذه الوظيفة بحد ذاتها غير آمنة.

وهذا هو المبدأ الذي نعمل عليه منذ الأزل.

صدفة لا حظت ردك :)

لا أختلف معك .. لكن نقطتان:

الأهم ما في الموضوع (بشكل غير قطعي لأن المعلومات سرية) أن عملية الاصطياد تتم عبر iframe و بعض أوامر الفلاش

النقطة الثانية أن معظم المواقع العربية التي يبرمجها (يعدل عليها أصحابها) تستعمل JScript بشكل مفرط (حتى أن بعض المنتديات المشهورة - لا أقصد هذا المنتدى - تستعمله بعد الدخول ليتم عرض الصفحة فقط أي لا بد لك بالمرور على هذه الإجراءات قبل الدخول - هذه لا يلاحظها من لا ينتبه لمثل هذه الأمور)

المهم أفضل شرح و ما قيل في هذا الموضوع من طرف أحد أكثر المهتمين بالحماية (Michal Zalewski) بعد طرح الموضوع من طرف أحد المختصين المعروفين (Dave Aitel )

lists.immunitysec.com/pipermail/dailydave/2008-September/005356.html كتب:

Dave Aitel

Thu Sep 25 10:27:15 EDT 2008

I went to the ClickJacking 20-Questions session yesterday at OWASP:

Essentially if your web page is in the same frame as another page you can slide them under your buttons/URLS using HTML such that when the user is clicking on your link, they instead really are clicking on some random place on a web page of your choice. This process is essentially invisible to the end user.

The difficult thing is finding out what to do with this (i.e. you have to look at gmail's interface and see if you can get them to do anything with just clicks - like set up a filter using CSRF first, then click "OK" to get all the user's email!)

So that's what it is. Seems real enough to me, although the name is gag-worthy. Rsnake says to "Use Lynx." One typical attack for a process that required lots of buttons to be clicked would be a flash game where people clicked a lot to shoot or something. Or perhaps a "hot or not".

You don't need Javascript to do this so noscript isn't going to help you (but it does make life easier). Not sure if HTML Email clients are vuln, but they might be.

Anyways, I'm giving a talk today at 4pm on "Corruption". If for whatever reason you don't want to see the talk (which includes a picture of a giraffe), there's another good talk going on at the same time slot by Chris Eng on how to crack custom crypto in session keys of web apps. Chris Eng and Kevin Dunn (now both at Veracode) are the best people I've ever seen at this sort of wacky stuff, so it's worth a viewing!

- -dave

lists.immunitysec.com/pipermail/dailydave/2008-September/005357.html كتب:

Michal Zalewski

Thu Sep 25 13:37:05 EDT 2008

On Thu, 25 Sep 2008, Dave Aitel wrote:

> I went to the ClickJacking 20-Questions session yesterday at OWASP:

Yes, it's a fairly nasty design problem that pops up now and then. Here are some of our thoughts on possible fixes, in case anyone wants to chime in of spot an obvious weakness in them before it's too late:

http://lists.whatwg.org/pipermail/whatwg-w...ber/016284.html

Cheers,

/mz

الأهم ما في الموضوع (على الأقل في رأيي):

lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016284.html كتب:

Dealing with UI redress vulnerabilities inherent to the current web

Michal Zalewski

Thu Sep 25 10:24:04 PDT 2008

For a couple of months now, along with a number of my colleagues at Google, we were investigating a security problem that we feel is very difficult or impossible to avoid on application side, and might be best addressed on HTML or HTTP level in contemporary browsers. These problems had recently gained some mainstream attention, and so we hoped to discuss potential solutions, and perhaps gain some traction for long-term fixes.

Problem definition: a malicious page in domain A may create an IFRAME pointing to an application in domain B, to which the user is currently authenticated with cookies. The top-level page may then cover portions of the IFRAME with other visual elements to seamlessly hide everything but a single UI button in domain B, such as "delete all items", "click to add Bob as a friend", etc. It may then provide own, misleading UI that implies that the button serves a different purpose and is a part of site A, inviting the user to click it. Although the examples above are naive, this is clearly a problem for a good number of modern, complex web applications.

Practical, real-world examples of such "UI redress" attacks were demonstrated in the past, and recently resurfaced on an OWASP conference (under the name of "clickjacking"); some references include:

* http://www.thespanner.co.uk/2008/02/11/csrf-chat/

* https://www.owasp.org/index.php/OWASP_NYC_A...2008_Conference

* http://lists.immunitysec.com/pipermail/dai...ber/005356.html

We feel that current web browser designs provide no adequate tools for web site owners to protect their applications against such attacks. The two workarounds often employed right now are:

1) Using Javascript hacks to detect that window.top != window to inhibit rendering, or override window.top.location. These mechanisms work only if Javascript is enabled, however, and are not guaranteed to be reliable or future-safe. If the check is carried on every UI click, performance penalties apply, too. Not to mention, the extra complexity is just counterintuitive and weird.

2) Requiring non-trivial reauthentication (captcha, password reentry) on all UI actions with any potential for abuse. Although this is acceptable for certain critical operations, doing so every time a person adds Bob as a friend on a social networking site, or deletes a single mail in a webmail system, is very impractical.

Other quick fixes are easy to come up with, but in general prove problematic in many usage scenarios. Based on our internal conversations, we have a number of proposals for approaches to how to address the issue, along with their pros and cons outlined. All these could be tweaked, combined, etc.; none of them seems quite ideal.

Proposed fixes:

1) Create a HTTP-level (or HTTP-EQUIV) mechanism along the lines of "X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes" that permits a web page to inhibit frame rendering in potentially dangerous situations.

Pros:

- Super-simple

Cons:

- "Opt-in", i.e. currently vulnerable sites remain vulnerable unless action is taken

- Can't be used for cases where IFRAME content mixing has a legitimate purpose (for example, cross-domain gadgets, certain types of mashups)

- Adds yet another security measure (along with cross-domain XHR, MSIE8 XSS filters, MSIE P3P cookie behavior, Mozilla security policies) that needs to be employed correctly everywhere to work - which is very unlikely to consistently happen in practice

- Along with the aforementioned security features, threatens to result in HTTP header or HTML HTTP-EQUIV size bloat that some sites may care about.

2) Add a document-level mechanism to make "if nested <show this> else <show that>" conditionals possible without Javascript. One proposal is to do this on the level of CSS (by using either the media-dependency features of CSS or special classes); another is to introduce new HTML tags. This would make it possible for pages to defend themselves even in environments where Javascript is disabled or limited.

Pros:

- Lightweight

- Far more fine-grained than proposal #1 (though still not perfect)

Cons:

- "Opt-in" (sites remain vulnerable unless action is taken)

- Might seem like an odd abuse of CSS / HTML

3) Add an on-by-default mechanism that prevents UI actions to be taken when a document tries to obstruct portions of a non-same-origin frame. By carefully designing the mechanism, we can prevent legitimate uses (such as dynamic menus that overlap with advertisements, gadgets, etc) from being affected, yet achieve a high reliability in stopping attacks.

[i like this one the most myself, but we were far from reaching any consensus.]

Algorithm description:

A ) Permit frames to be nested arbitrarily by default.

B ) If anything is to be drawn partly or fully on top of a region occupied by a nested IFRAME (in a callback from the renderer), look up the parent of the obstructing visual element drawn (that is, the party in charge of element's positioning). Always allow the element to be drawn, but if the parent is not same-origin with the target of an obstructed IFRAME, set a flag to disable UI input to that obstructed IFRAME (i.e., have the browser sink all UI events from now on). We may also gray out the disabled IFRAME (and maybe allow CSS to customize this behavior for specific IFRAMES).

C) Treat a case where top-left corner of the IFRAME is drawn out of a visible area (CSS negative margins, etc) as a special case of being obstructed by the owner of a current rendering rectangle (another IFRAME or window.top) and carry out the same comparison.

D) Once the obstruction is removed (say, a menu folded back), initiate a security timer (500-1000 ms or so) to eventually re-enable UI input to the IFRAME.

E) Cases where a non-same-origin IFRAME is newly spawned by Javascript, or same-origin -> non-same-origin location updates takes place, should be treated as special cases of the IFRAME being uncloaked, and result in UI event lockout until a security timer expires.

F) Regardless of the aforementioned mechanism, do not permit an IFRAME target that is not same-origin with its parent document to invoke .focus() or to reposition content using URL anchors. This is to make sure that the top-left corner of the page as seen by the user always displays the top-left corner of the actual page.

A potential optimization for D) and E), to minimize any potential impact where attacks are unlikely to succeed, is to:

Permit a short window of opportunity (0.5 second, perhaps) following initial page load, as well as possibly mouse clicks, during which cross-domain IFRAMEs may be revealed with no timer penalty, based on the assumption that immediate and involuntary UI actions are unlikely to follow

...or alternatively:

Disable UI events or initiate timeouts only if cursor is within a certain radius of the uncloaked non-same-origin frame, based on the same assumption

Pros:

- Works by default

Cons:

- Moderately complex and kludgy

- In implementations, would require callbacks from the renderer to detect obstruction, as opposed to making decisions without this knowledge

- Further investigation is needed to verify that this doesn't break the legitimate and common practice of some sites

4) Enforce a click-to-work mechanism (resembling the Eolas patent workaround) for all cross-domain IFRAMEs.

Pros:

- Works by default

- Very simple

Cons:

- May be cumbersome for users

- May not play well with gadgets, advertisements, etc.

5) Rework everything we know about HTML / browser security models to make it possible for domains and pages to specify very specific opt-in / opt-out policies for all types of linking, referencing, such that countering UI redress attacks would be just one of the cases controlled by this mechanism.

Pros:

- Awesome in theory, security-wise

Cons:

- Not really going to happen any time soon

Cheers,

/mz

ملاحظة : نقلت كل النص مع الإشارة إلى الروابط فقط في حال كان هناك حظر للدخول أو (مستقبلا - من يدري) غياب المحتوى.

أتمنى أن نرى تعليقات أكثر خصوصا من طرف مطوري الواب الذين لديهم خبرة لا بأس بها في الميدان - طبعا الهدف زيادة الوعي في التصفح و استعمال الأنترنت.

:)

السلام عليكم،

قرأت الاقتباسات حتى نقطة الحلول المقترحة ولم أتابع .. سأقرأها لاحقاً.

في النقطة التي يتم ذكر مسألة استخدام iframe ضمن الصفحة الأصلية لتمرير بيانات وهمية أو جعل المستخدم يقوم بالنقر على زر ما بغرض غير أخلاقي.. كل هذا كيف له أن يتم في بيئة آمنة من قبل طرف مطور صفحة الويب تلك؟

على سبيل المثال، موقع Refriendz.com السابق - اكتشفت ثغرة فيه في بعض البارامترات التي سمحت لي بتمرير سكربتات جافاسكربت أو/و HTML بدون مشاكل بحيث يتم حفظها واعادة تشكيلها في الصفحة دون فحص لهذه القيم.

هذا الأمر كان جيد، لكن السئ في الأمر أني لا أستطيع القيام بأي شئ مفيد، فسحب بيانات الكوكيز غير مفيد، لأنه يعتمد على الـ session authentication.

لكي لا يكون هناك شك من قبل المستخدم في النقر على زر غريب أو ما شابه أقوم بوضعه ضمن iframe واعتمد على DOM و جافاسكربت في تنفيذ شئ ما، قمت باستخدام AJAX في الحصول على إمكانية تنفيذ ما أريد في الصفحات الأخرى متضمناً هذا التعديل في بيانات التسجيل أو الحصول عليها من قبل الصفحة المخصصة لهذا، فكما تعرف AJAX تستطيع حمل بيانات الـ authen لكن JAVASCRIPT لا تستطيع هذا بين الصفحات المختلفة.

الجميل في الأمر أني أيضاً كنت قادراً على جعل أي زائر للصفحة الرئيسية للـ profile يتعرض لهذه الإصابة التي يتم كتابتها في صفحته الشخصية أيضاً وببعض الـ HTML الخاطئة أقوم بحجب إمكانية تحرير البروفايل مما يمنعه من تحريره وإزالة السكربت المحقون (إلا لو قام بتحميل نسخة من الصفحة على جهازه ومن ثم إجراء التعديلات بشكل يدوي ومن ثم تحرير مسار الـ forms وما إلى هذا وإعادة الحفظ للبيانات الجديدة).

الموقع كان fairly large، أتصور أنه حتى تلك اللحظة ضم حوالي 100,000 عضوية. وهناك عضويات أكثر زيارة, لو قمت بنقل العدوى لصفحاتهم يمكن نقل العدوى بشكل سريع بين العضويات الأخرى. لا أستطيع أن أحدد scale الإصابة بكل الأحوال. مثال على مثل هذه الثغرات: Samy Worm أو المسماة أيضا MySpace Worm التي أصابت موقع MySpace وبلغت الإصابة في بضع ساعات مليون إصابة تقريباً.

طبعا موقع Refriendz لا شئ مقارنة بـ MySpace.

المهم، هاتان الثغرتان من الممكن تفاديهما وأي Clickjacking أخرى بنظري عندما تكون البيئة التي تعمل عليها/تتصفحها آمنة.

عندما ينتفي الشرط الأخير، تستطيع أن تقوم بخلق ثغرات من كافة الأنواع.

وهذا ما يجعل (و لا زالت) المواقع التي تسمح للمسجلين بتحرير الصفحات (ملاحظة لم استعمل Refriendz و Facebook) خطيرة

فقط نقطة على الطريق: ما يجعل مدونات Wordpress على موقعها أأمن من BlogSpot هو أن الأخيرة تسمح بالتعديل على HTML بينما الأولى تسمح فقط بالتعديل على CSS. لذلك الكثير من مدونات BlogSpot غير آمنة من ناحيتي المصداقية و الخصوصية (حذار من الرسائل -التعليقات- المجهولة التي تحتوي على عنوان مدونة)

كذلك كما ذكرت أخونا Xacker مواقع التعارف و الصفحات الشخصية لا تسلم من هذه (من الجانب العربي موقع جيران مرة على مرة توزع رسائل مشبوهة للصداقة، ما يريب هو إذا كانت صفحتك بالعربية تأتيك رسالة من فتاة :pwease: أمريكية، أو خمن من أين، لا تعرف العربية تدعوك للصداقة (على الأقل من كان على دينه سلم :happy: ) و طبعا إسمها لا يخلو من رابط الصفحة الشخصية)

بخصوص مواقع اللعب على المباشر لا أعرف لأنني لم أجربها.

:)

القصة لم تنتهي بعد .. بعد الانتهاء من القراءة أطلق العنان لمخيلتك و تصور ابداع من يعيشون في الخنادق المعلوماتية :D

اقتباس

A Flash Player vulnerability could allow attackers to gain control of a user's webcam and microphone, according to a security advisory issued by Adobe. The company has issued a workaround; however a patch won't come until later. As always, Web surfers should be careful where they're clicking

المزيد في الرابط أعلاه

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

اقتباس

Summary

Adobe is aware of recently published reports of a ‘Clickjacking’ issue in multiple web browsers that could allow an attacker to lure a web browser user into unknowingly clicking on a link or dialog. It has been determined that this potential "Clickjacking" issue affects Adobe Flash Player. Adobe is working to address this issue in an upcoming update to Flash Player

المزيد في الرابط أعلاه

:)

أصبح الموضوع مشوق أكثر:

http://ha.ckers.org/blog/20081007/clickjacking-details/

PoC: http://guya.net/security/clickjacking/game.html

http://blog.guya.net/2008/10/07/malicious-...g-clickjacking/

مشوق و الذي ظهر بعد التصليحات و ما خفي (لم يصلَّح) أكثر تشويقا :wink::)

ملاحظة الرابط الثاني لأخونا Xacker هو مثال عن الاختراق ، للأمانة المسؤولية على المستعمل

لمن لا يستعمل webcam مثلي هذا الفيديو يوضح العملية

:)

الظاهر أن هذا الموضوع عمره طويلة معي :lol:

منذ يومين تقريبا كان تحديث للإضافة NoScript

الإضافة مهمة بحيث تم تقريب ما فهم من طريقة Clickjacking و تطبيق بعض أفكار الحماية و كانت النتيجة ClearClick

هذه صورة

http://hackademix.net/2008/10/08/hello-cle...e-clickjacking/

فقلت كل من يستعمل FF و هذه الأداة علم بالأمر

لكن صدفة اليوم عندما أردت معرفة احصائيات موقع خاص لي (طبعا ذهبت إلى google analytics) و بعد محاولة ادخال اسم المستخدم ظهرت النافذة

استعملت FireBug لأارى الكود

فائدة للإفادة :happy:

:)

merouane كتب:

الإضافة مهمة بحيث تم تقريب ما فهم من طرقة Clickjacking و تطبيق بعض أفكار الحماية و كانت النتيجة ClearClick

Hello ClearClick, Goodbye Clickjacking!

أخي Merouane هل يمكن أن تشرح أكثر؟

djug كتب:

أخي Merouane هل يمكن أن تشرح أكثر؟

ماذا أشرح ؟؟

كل المشاركات المهمة لديها روابطها الأصلية (بدأت أبتعد عن الترجمة إلا قليلا)

مشاركات أخونا Xacker أيضا ذات فائدة كبيرة (أنظر آخر روابط وضعها)

بالنسبة للمشاركة الأخيرة أحببت فقط أن ألفت النظر إلى فائدة التحديثات الأخيرة للإضافة NoScript التي تمكن من معرفة إذا كان عنصر مخفي عند مرور الفأرة بالضغط أو عند الكتابة

بمعنى أخر التحكم في سير المعلومات الصادرة منك

للمزيد أنظر الرابط الأول لآخر مشاركة لأخونا Xacker

و الفيديو Clickjacking Camjack Demonstration

أيضا مقالة Michal Zalewski (في المشاركة رقم 14) مهمة و هو سبب ما تراه باسم UI redress

noscript.net كتب:

New and improved ClearClick anti-Clickjacking technology to disable user interaction with partially obstructed or not clearly visible embedded objects. Enabled by default on untrusted pages, you can configure it to work on trusted pages as well in NoScript Options|Plugins; most false positive have already been eliminated in 1.8.2.2, and enforcing it everywhere will likely become the default after some other testing testing

ملاحظة : توجد روابط تعتبر من أمهات المقالات التي تتحدث عن هذه التقنية في الاختراق، لم أضعها لأني لا أثق فيها من ناحية الخصوصية (يعني الزوار فئران تجارب للاختراق) لكن بقراءة المشاركات و الروابط يمكن للقارئ التوصل إليها.

قبل المغادرة أحببت أن أشكر Xacker لمشاركاته القيمة و الإضافات التي هي مساهمة في زيادة الوعي أو ربما إيقاظ تفكير شخص ما قد يبرع في هذا المجال (حماية الشبكات و الموقع الإلكترونية)

فيما يخصني لن أتابع نشر أخبار هذه التقنية ..

و السلام ختام

:)

أهلا أخ مروان، من حقك ألا تكون تريد التكلم عن الموضوع أكثر من هذا لكن بكل الأحوال Google موجود ومن يريد الوصول إلى شئ بخصوص الموضوع ويريد استغلاله وكان على مستوى معين من المعرفة فسيصل إليه أما الـ script kiddies فحتى لو وصلوا لن يعرفوا ما عليهم القيام به حتى بقراءة أدق التفاصيل.

بكل الأحوال عدت للموضوع لأقول بأنه حتى الآن تم طرح 3 إصدارات ثانوية أخرى من NoScript بعد المشكلة خلال الأسبوع الماضي والإصدار الحالي هو: 1.8.2.8