A partner site allows the host site to display their project and their tools on the host domain in their own URL, with their own branding and styling. Partner sites live under a separate domain in an organization, or a sub domain is created for each partner site e.g. for a connect2u partner site the sub domain in XYZ organization will be created. It can be accessed through a URL such as https://www.connect2u.xyz.com.

Partner-site vulnerabilities

  • Cross-site scripting (XSS) holes may be present in partner sites which allow developing vulnerable applications in partner site. Through this one can insert unfiltered character. And one could then exploit this loophole to execute arbitrary scripts.
  • Partner sites can store data from the host domain without any restriction. It can store users’ behavior, usage and other details which can be illegally used.

Issues associated with partner sites


“Likejacking” is a Facebook-specific version of an attack called “clickjacking.” Clickjacking (also known as user-interface or UI redressing and IFRAME overlay) is an exploit in which malicious code is hidden beneath apparently legitimate buttons or other clickable content on a website. The purpose of the attack is to get you to click items on a webpage without your knowledge.

Facebook attackers present a web page that actually has two layers. The back layer is designed with a Facebook “Like” button configured to follow your mouse cursor. The front layer shows whichever lure you are unfortunate enough to be tricked by. For example, CSS can be used to overlap two buttons and make the top one transparent. Users will only see the visible one at the bottom, but if they click it they press the hidden button. No matter where you click on the webpage, you are actually clicking the Facebook Like button and further spreading the spam.

One reason this attack works is that Facebook does not require any confirmation when you click the Like button. Though confirmation would not entirely prevent the attack, it would complicate the attack and potentially discourage its active exploitation.

Likejacking Attack can be used for:

  • Posting on the Facebook walls of unsuspecting users.
  • Deleting users’ profiles.
  • Making users social networking profile information public if it was previously private;
  • Forcing link sharing on Facebook and other link sharing networks.

Account Compromise

On a WordPress site, strong restrictions for strengthening passwords can be enforced for users who make separate accounts in the site so that their account is not compromised. However, in case of users who use their OpenID to create an account in WordPress site, the strength of OpenID passwords cannot be guaranteed. If the OpenID provider is not enforcing regulations on passwords, the accounts may get compromised and thereby it might affect the WordPress site. For example, if a user’s open-id account is compromised, the attacker will have access to the user’s entire website profile. He can then use this leverage to delete the user’s profile, delete content or try to cause an application level Denial of Service attack.


The normal practice on the internet is to have different login information for every site a person wishes to make an account. This requires keeping track of the corresponding credentials for all those websites. This task is simplified by the concept of OpenID. The purpose of OpenID is to realize the concept of having a common, single identity for multiple sites. Many OpenID service providers are present today and numerous sites are using OpenID system for authentication. The most commonly used OpenID by users is their email ID.

How OpenID works

When you log into an OpenID-enabled website using your OpenID, the website you are visiting transfers you to your OpenID service provider, as specified by your OpenID (which is your CC Network profile URL). Once at your OpenID service provider, you can log in and, if you choose to do so, provide information back to the website you are visiting. Once you have logged in, your OpenID service provider transfers you back to the website you are visiting, thereby giving you access to the area of the website (such as your account or profile information), that would have otherwise required you to enter your website-specific login.

OpenID Protocol Vulnerability

The Diffie Hellman key exchange is used by Open ID to send user details over internet.

Step 1: Both RP & OP agree on two values “g” and “p”. The values of “g” and “p” can be known to anybody – even other than the RP and the OP. Under the context of OpenID, these values are defined in the OpenID Authentication Specification. Basically, “p” is a large prime number and “g” is a small number.

Step 2: RP selects a secret number, say “x” – which is typically a large number and computes another number, “X” – with the values of “g” and “p”, where X = g^x mod p. Now RP can share “X” with OP [or anybody else] – which is the public key of RP – but it will still maintain “x” as a secret.

Step 3: OP will also select a secret number, say “y” – which is typically a large number and computes another number, “Y” – with the values of “g” and “p”, where Y = g^y mod p. Now OP can share “Y” with RP [or anybody else] – which is the public key of OP – but it will still maintain “y” as a secret.

Step 4: Since the public key of OP – “Y” is known to anyone – RP can derive the Diffie-Hellman secret key [Kx] between OP and RP. Kx = Y^x mod p

Although, “Y” is known publicly – “x” is kept as a secret at the RP – so nobody other than RP, can compute the value of Kx.

Step 5: Since the public key of RP – “X” is known to anyone – OP can derive the Diffie-Hellman secret key [Ky] between OP and RP. Ky = X^y mod p

Although, “X” is known publicly – “y” is kept as a secret at the OP – so nobody other than OP, can compute the value of Ky.

Step 6: All set. Under the Diffie-Hellman key-exchange, Kx=Ky – so OP and RP shared a secret key between each other.

OpenID Authentication supports both a “smart mode” and “dumb mode” to accommodate Consumers of differing capabilities. A smart Consumer does a little more work at the beginning to save itself work later, but requires local caching of state information. A dumb Consumer is completely stateless, but requires an extra HTTP request.

Under “smart mode”, it is recommended that RP first submits an associate request (associate) to the End User OP and requests a shared secret, if the RP does not already have one cached.

So, the request for “Association” will take place after the “Discovery” – that is after the OP server url has been discovered from a given OpenID.

The “Association” request is initiated by the RP using direct communication message called “associate” with an HTTP POST.

Some of the important parameters included in an “associate” request.

1. openid.mode : This will have the value “associate” – indicates OP that this is an “associate” request.

2. openid.assoc_type : This defines the algorithm to be used to sign subsequent messages. OpenID 1.1 supported only HMAC-SHA1. HMAC-SHA256 was added in OpenID 2.0. In other words once an “association” being established between OP and RP – the same will be used for subsequent OpenID authentication requests between these OP and RP.

3. openid.session_type : This defines the method used to encrypt the association’s MAC key in transit. MAC key is the shared key established between OP and RP. This should not be confused  with the Diffie-Hellman shared secret. Diffie-Hellman shared secret is used to protect the MAC key [shared key] – more explanation further later.

openid.session_type can have any of the following values : No-encryption,  DH-SHA1,  DH-SHA256 [Added in 2.0].

In a “no-encryption” association session, the OP sends the association MAC key in plain-text to the Relying Party. This makes it possible for an eavesdropper to intercept the key and forge messages to this Relying Party when not using transport layer encryption. Therefore, “no-encryption” association sessions MUST NOT be used unless the messages are using transport layer encryption.

The “DH-SHA1″ and “DH-SHA256″ association session types use Diffie-Hellman Key Exchange to securely transmit the shared secret – that is MAC key. In other words if you use “DH-SHA1″ or “DH-SHA256″ as the association session type – first OP and RP will derive a Diffie-Hellman shared secret, as explained in the beginning of this post, and will use that shared secret to encrypt the MAC key.

The following parameters are common to requests whose requested association session type is “DH-SHA1″ or “DH-SHA256″.

4. openid.dh_modulus : This is the value of “p” used in Diffie-Hellman key-exchange, where the default value defined in the spec.

5. openid.dh_gen : This is the value of “g” used in Diffie-Hellman key-exchange, where the default value defined in the spec.

6. openid.dh_consumer_public : This is the public key of RP for Diffie-Hellman key-exchange [X].

Once the OP receives the “associate” request – it will generate a MAC key and encrypt the MAC key [if "DH-SHA1" or "DH-SHA256" being used] with the Diffie-Hellman shared secret. OP will also share it’sDiffie-Hellman public key with the RP through the response – so RP can derive the Diffie-Hellman shared secret from it and decrypt the MAC key.

When this is happening, a “Man in the middle” attack allows a hacker to reverse guess the encrypted MAC key since the key is shared.

Vulnerability of OpenID to DNS Attacks

OpenID is not designed to require the prior exchange of security information between parties for the process to work. Instead, it relies on the integrity of the underlying DNS system to ensure that identity is vouched for by the “correct” trust provider. This means that, if the underlying DNS system is compromised, authentication is undermined, as it is impossible to tell whether an entity vouching for an identity can be trusted.

An attacker who can alter the result of a relying-party’s DNS lookup of the OpenID host can masquerade as the OpenID provider of a given user and gain access to the corresponding account at the web site in question. Of course, a simpler version of such a DNS poisoning attack against non-SSL-protected web sites can also be used for highly effective phishing attacks directly against users of a web site. In short when an OpenID URL is not protected by SSL (and many are not), the OpenID protocol is vulnerable to DNS attacks.

Protecting the Site (Server Side)

Frame Killer Scripts

Website users can be protected from click-jacking attacks by using a bit of Java code called a Frame Killer. This stops any of the triggered content from being showed within a frame, which prevents clickjackers from making their move. The following snippet is a good cross-browser code set:


if (self == top) {

var theBody = document.getElementsByTagName(‘body’)[0];

theBody.style.display = “block”;

} else {

top.location = self.location;



Using this, most click-jacking attempts will be thwarted as well as several other types of attacks that rely on frames being used within a website.

Overcoming Man in the middle attack

Whether or not the MAC key for Diffie Hellman has been encrypted, the same can be used by the “Man in the middle” in order to imitate the original sender/receiver. This will lead to the “Man in the middle” being able to authenticate as someone else. In cases where the MAC key has not been encrypted using SHA or SHA256, things get worse. The MAC key  is in text form, and can be used by the hacker directly for other purposes.

HTTPS is a secure HTTP protocol designed specifically for these purposes, i.e against Man in the middle attacks.

HTTPS ensures that the data is communicated using SSL (which uses various techniques like RC4, MD5 and SHA256). This way, the man in the middle, cannot decrypt the message sent without the SSL keys (even with a replay attack).

Hence, using HTTPS for OpenID authentication ensures the safe authentication of the user.

DNS Safety

  • Use Https: If the OpenID provider is not using http redirects to send discovery to the https version of the url then your account is vulnerable to being hijacked at any OpenID relying party that is vulnerable to cache poisoning and other DNS attacks. So, the simplest solution is to make sure that the OpenID provider is trusted and is using https. A simple way to test this is to type your OpenID directly into your browser bar. If you don’t see yourself redirected to an https version of the URL, then it cannot be trusted.
  • Restrict access: Administrators, particularly those who are unable to apply a patch, can limit exposure to this vulnerability by restricting sources that can ask for recursion. Note that restricting access will still allow attackers with access to authorized hosts to exploit this vulnerability.
  • Run a Local DNS Cache: In lieu of strong port randomization characteristics in a stub resolver, administrators can protect their systems by using local caching full-service resolvers both on the client systems and on servers that are topologically close (on the network) to the client systems.
  • WordPress: In order to secure the WordPress site, it is better not to give Administrator privilege to any OpenID user. It is most advisable to give all OpenID users only “unprivileged” access.
    • ShareingSites:  An attacker has access only to the “Like” and “Share” buttons on WordPress. He can, at most, Like or un-Like the page and share or unshare articles.
    • OpenID:  An attacker can add or delete comments. If these comments are subject to moderation, the attackers’ posts can be removed easily. A Captcha plugin can also prevent mass comment posts by attackers.

Attackers can also try to cause application level DoS attacks by loading heavy pages repeatedly. A wordpress plugin can be written to prevent DDoS attack.

Protecting Yourself (Client Side)

Browser Extensions

The NoScript browser extension improves web client security by applying a Default Deny policy to JavaScript, Java, Flash and other active content and provides user with an one-click interface to easily whitelist sites they trust for active content execution. It also implements the most effective Cross-Site Scripting (XSS) filters available on the client side, covering Type-0 and Type-1 XSS attacks; ClearClick, the only specific browser countermeasure currently available against ClickJacking/UI redressing attacks, and many other security enhancements, including a limited form of protection against Cross-Site Request Forgery (CSRF) attacks: POST requests from non-whitelisted (unknown or untrusted) sites are stripped out of their payload and turned into idempotent GET requests.

It can be downloaded using the below link.


NoScript is compatible with all Mozilla-based browsers. Many of the threats NoScript is currently capable of handling, such as XSS, CSRF or ClickJacking, have one common evil root: lack of proper isolation at the web application level. Since the web has not been originally conceived as an application platform, it misses some key features required for ensuring application security. Actually, it cannot even define what a “web application” is, or declare its boundaries especially if they span across multiple domains, a scenario becoming more common and common in these “mashups” and “social media” days.

Also an additional and advanced module in NoScript called Application Boundaries Enforcer (ABE) module is hardening the web application oriented protections by delivering a firewall-like component running inside the browser. This “firewall” is specialized in defining and guarding the boundaries of each sensitive web application relevant to the user (e.g. webmail, online banking and so on), according to policies defined either by the user himself, or by the web developer/administrator, or by a trusted 3rd party.


# This one defines normal application behavior, allowing hyperlinking

# but not cross-site POST requests altering app status

# Additionally, pages can be embedded as subdocuments only by documents from

# the same domain (this prevents ClickJacking/UI redressing attacks)

Site *.somesite.com

Accept POST SUB from SELF https://secure.somesite.com

Accept GET



# This one guards logout, which is foolish enough to accept GET and

#therefore we need to guard against trivial CSRF

Site www.somesite.com/logout

Accept GET POST from SELF



# This one guards the local network, like LocalRodeo

# LOCAL is a placeholder which matches all the LAN

# subnets (possibly configurable) and localhost


Accept from LOCAL



# This one strips off any authentication data

# (Auth and Cookie headers) from requests outside the

# application domains, like RequestRodeo

Site *.webapp.net

Accept ALL from *.webapp.net



# This one allows Facebook scripts and objects to be included only

# from Facebook pages

Site .facebook.com .fbcdn.net

Accept from .facebook.com .fbcdn.net



Bookmarklets are derived from a combination of “bookmarks” and “applets”. It is mostly unobtrusive JavaScript i.e. a quiet application only provoked only on click or other specific action. It is included in page as a hyperlink on the web page. Bookmarklets are saved and used as normal bookmarks. They normally execute javascript that has access to the current page, which they may inspect and change.

Possible vulnerability may arise for same reason as using javascript i.e. CSRF vulnerabilities. Also, the Same origin policy for JavaScript may prevent a document or script loaded from one origin from getting or setting properties of a document from another origin. Mozilla considers two pages to have the same origin if the protocol, port (if one is specified) and host are the same for both pages.


The Like button lets a user share your content with friends on Facebook. When the user clicks the Like button on your site, a story appears in the user’s friends’ News Feed with a link back to your website.

When your Web page represents a real-world entity, things like movies, sports teams, celebrities, and restaurants, use the Open Graph protocol to specify information about the entity. If you include Open Graph tags on your Web page, your page becomes equivalent to a Facebook page. This means when a user clicks a Like button on your page, a connection is made between your page and the user. Your page will appear in the “Likes and Interests” section of the user’s profile, and you have the ability to publish updates to the user. Your page will show up in same places that Facebook pages show up around the site (e.g. search), and you can target ads to people who like your content.

There are two Like button implementations: XFBML and Iframe. The XFBML (also available in HTML5-compliant markup) version is more versatile, but requires use of the JavaScript SDK. The XFBML dynamically re-sizes its height according to whether there are profile pictures to display, gives you the ability (through the Javascript library) to listen to like events so that you know in real time when a user clicks the Like button, and it always gives the user the ability to add an optional comment to the like. If users do add a comment, the story published back to Facebook is given more prominence.

Security Issues Related with LIKE BUTTON

The security issues related to like button of Facebook are likejacking, likeswitching, phishing etc.


Like switching is an alternative take on Like Jacking — the difference is that the user is explicitly shown a like button with a prestigious like count and familiar friends first. When a user reaches out to click on it, the like button is swapped out for a different one, triggered by an onmouseover event from the rectangle around the button. So in fact he likes a page he never meant to.


The concept of reputation misrepresentation is quite simple: a not-so-popular website can use another website’s reputation to make the   site seem more reputed or established to the user.

This is also in a way a form of social engineering as the victim is tricked into believing that the website he is on is a legitimate one since all his friends like it. A website could show the like count of a famous website, say IMDB. Simply put, as of now, any website(e.g. a web store) can claim they are popular (especially with your friends) to gain your trust. Since Facebook doesn’t check referrer information, Facebook really doesn’t have the power to do anything about this either. A possible solution is to include verifying information inside the like button, which ruins the simplicity of it all.


The like buttons on any webpage provide a way to get the username and password of unsuspected phishers. When the user is not logged into Facebook and when he likes something, he is asked to login to like the webpage. It is trivial to create a phished page which asks the victim’s Facebook username and password. If the user is careful he may notice the phished page, but in most cases he would just give the username and password and be done with it.


One Response to Partner Site Vulnerabilities

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <p>

This site is protected with Urban Giraffe's plugin 'HTML Purified' and Edward Z. Yang's Powered by HTML Purifier. 52436 items have been purified.