Microsoft Research report shows how risky single sign on can be without good integration and better support from Web service providers such as Google and Facebook.
(click image for larger view)
Slideshow: 10 Massive Security Breaches
As more organizations tap into single sign-on (SSO) schemes through Web services providers such as Google and Facebook, new research suggests that they must better plan how they implement SSO APIs lest they leave users open to attack. New findings by Microsoft Research found troubling logic flaws in SSO for Facebook, Google ID, PayPal, and other Web services that threaten a large number of users online.
Though each flaw had its own unique characteristics, all eight detailed in the report (PDF) had one trait in common.
"All these flaws allow the attacker to sign in as the victim to her accounts on the websites using SSO services even without knowing the victim's password," said Dr. XiaoFeng Wang, associate professor of computer science at Indiana University at Bloomington and co-author of the report with Rui Wang and Shuo Chen.
Wang and his team hope the report is a wake-up call for both the developers of websites using the SSO services and those providing the services, between whom there seems to be a disconnect as to who is responsible for hardening the SSO application. Further obscuring the matter is the fact that the SSO is going through browsers, whose behaviors are very complicated, Wang says.
"IT decision-makers should realize the security risk that comes with the convenience of SSO. Most problems we discovered actually can be fixed through correct integration on the website part. In other words, if the developer of these websites incorporate such SSO services carefully, SSO can be more secure," Wang says. "To make this happen, however, we also expect the help from the service provider side. They need to offer good integration supports, including well-specified documentation, verified secure code template, and other [support] to guide their customers during the integration process, which according to our findings, is very easy to get wrong."
SSL is widely deployed, yet enterprises still struggle to manage it and ensure its effectiveness. Companies must understand the threats, know how to use SSL internally, and assure it functions properly and protects their data. In our SSL Authentication report,? we show you how to address the security and operational issues inherent in creating and managing internal SSL certificate authorities. (Free registration required.)
New Best Practices for Secure App DevelopmentThe transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Published: 2015-10-15 The Direct Rendering Manager (DRM) subsystem in the Linux kernel through 4.x mishandles requests for Graphics Execution Manager (GEM) objects, which allows context-dependent attackers to cause a denial of service (memory consumption) via an application that processes graphics data, as demonstrated b...
Published: 2015-10-15 Cross-site request forgery (CSRF) vulnerability in eXtplorer before 2.1.8 allows remote attackers to hijack the authentication of arbitrary users for requests that execute PHP code.
Published: 2015-10-15 Directory traversal vulnerability in QNAP QTS before 4.1.4 build 0910 and 4.2.x before 4.2.0 RC2 build 0910, when AFP is enabled, allows remote attackers to read or write to arbitrary files by leveraging access to an OS X (1) user or (2) guest account.
In past years, security researchers have discovered ways to hack cars, medical devices, automated teller machines, and many other targets. Dark Reading Executive Editor Kelly Jackson Higgins hosts researcher Samy Kamkar and Levi Gundert, vice president of threat intelligence at Recorded Future, to discuss some of 2016's most unusual and creative hacks by white hats, and what these new vulnerabilities might mean for the coming year.