Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Security The Internet

LinkedIn's Own CSS Abused For Clickjacking Attacks 12

An anonymous reader writes: LinkedIn has fixed a security bug that allowed attackers to use its own CSS code for clickjacking attacks. Basically attackers can create blog posts and load CSS classes from LinkedIn's own stylesheets. If a reader lands on that blog post, then a malicious link can be shown for the entire area of the page. Not something "unique" since this type of method is quite well-known, but you don't generally expect to find these kind of attacks on LinkedIn's own platform. (Here's a link to the LinkedIn security blog. Sorry for not linking to the particular blog — LinkedIn has a weird URL policy. It's the first one.)
This discussion has been archived. No new comments can be posted.

LinkedIn's Own CSS Abused For Clickjacking Attacks

Comments Filter:
  • by JustAnotherOldGuy ( 4145623 ) on Friday November 27, 2015 @06:01PM (#51015277) Journal

    "...a link to the LinkedIn security blog"

    Oh The Irony, it's sooooooooo delicious.

    Forgive me if I decline to click on a link that's on the very site that the security vulnerability story is about. I was born at night, but not last night.

  • by guruevi ( 827432 )

    This is more of a browser issue that allows content to be loaded from domains not in the original request. A lot of malware can be prevented that way. If you really need to use 3rd party content, let your domain http server proxy the request (and cache it), that way you also prevent content being loaded you didn't intend to load. It also will reduce load times on your pages as there is no overhead on a million dns requests and different servers being involved.

    • You didn't read the article did you? There was no 3rd party content, the attack used Linkedin's OWN CSS!
  • by MisterSquid ( 231834 ) on Friday November 27, 2015 @09:43PM (#51015925)

    I'm a little sheepish about having to ask a question to understand the nature of this bug. Hopefully someone is willing to provide an explanation.

    So, I understand the content/markup could be loaded via JSON (I'm presuming an AJAX call) and that the vulnerability was a CSS class that allowed a link inside the JSON to be styled to cover the entire page, thus maximizing the likelihood of an unsuspecting user clicking on the target link (malicious or not).

    My question is "Did this technique merely maximize the likelihood of clicking on a link already on the page?" From what I can understand the possibly malicious link has to already reside in the JSON, the CSS vulnerability simply took that link and expanded it to cover the entire page.

    Am I missing something here? Thanks, in advance, for any clarification.

  • This is the WWW, where links are what make the damned thing work! Thanks LinkedIn for trying to crawl back into a cave.

No spitting on the Bus! Thank you, The Mgt.

Working...