Tuesday, December 1, 2015
Followup: can xss attacks embed hosted script?
Cameron asked a great question today about the level of access a script hosted elsewhere might have when that script was called through an XSS attack. Is that allowed, he asked, since the script is not hosted on the hacked site?
There is a web security policy called same origin, which is supposed to help prevent these sorts of things. Basically, it prevents a web page from gaining access to data in another web page, unless they are on the same site.
Unfortunately it does not prevent a page at one site from embedding script it hosts in a page at a different site. This is makes XSS attacks just a bit easier, and is a tradeoff we accept for all the non-malicious benefits of embedding.
We also mentioned the dangers of html5 and native client in this context. You can learn more about this in OWASP's video on html5.
Professor Watson
Tuesday, February 19, 2013
Find: Facebook, Twitter, Apple hack sprung from iPhone developer forum
Facebook, Twitter, Apple hack sprung from iPhone developer forum

The website used to infect engineers at Facebook with espionage malware has been identified as an iPhone developer forum by people close to the investigation into the hacking incident.
That page, at the iPhone developer website iphonedevsdk.com, was used to expose visitors to a previously undocumented vulnerability in Oracle's Java browser plugin. The "zero-day" exploit allowed the attackers to install a collection of malware on the Java-enabled computers of those who visited the site. Ars readers shouldn't visit the site because it still may still be compromised.
iphonedevsdk.com is an example of a "watering hole" attack. These attacks compromise a site popular with a population of desired hacking victims, using security vulnerabilities to install code on the Web server hosting it, which injects attacks into the HTML sent to its visitors. In this case, the site, which hosts a Web forum for iPhone developers, netted the hackers access to the computers of software engineers and developers working on mobile application projects for a number of companies, including Facebook. The exploit was the source of the attack on Twitter that led to the theft of Twitter usernames and passwords, according to a source familiar with the attack, and was used to infect computers belonging to Apple engineers. The source requested anonymity because he was not authorized to provide the details to the press.
Sunday, February 17, 2013
Find: Securing your website: A tough job, but someone's got to do it
Securing your website: A tough job, but someone's got to do it

In 2006, members of a notorious crime gang cased the online storefronts belonging to 7-Eleven, Hannaford Brothers, and other retailers. Their objective: to find an opening that would allow their payment card fraud ring to gather enough data to pull off a major haul. In the waning days of that year they hit the mother lode, thanks to Russian hackers identified by federal investigators as Hacker 1 and Hacker 2.
Located in the Netherlands and California, the hackers identified a garden-variety flaw on the website of Heartland Payment Systems, a payment card processor that handled some 100 million transactions per month for about 250,000 merchants. By exploiting the so-called SQL injection vulnerability, they were able to gain a toe-hold in the processor's network, paving the way for a breach that cost Heartland more than $12.6 million.
The hack was masterminded by the now-convicted Albert Gonzalez and it's among the most graphic examples of the damage that can result from vulnerabilities that riddle just about any computer that serves up a webpage. Web application security experts have long cautioned such bugs can cost businesses dearly, yet those warnings largely fall on deaf ears. But in the wake of the Heartland breach there was no denying the damage they can cause. In addition to the millions of dollars the SQL injection flaw cost Heartland, the company also paid with its loss of reputation among customers and investors.
Thursday, January 10, 2013
Find: Yikes! Extremely critical Ruby on Rails bug threatens more than 200,000 sites
Extremely critical Ruby on Rails bug threatens more than 200,000 sites
Hundreds of thousands of websites are potentially at risk following the discovery of an extremely critical vulnerability in the Ruby on Rails framework that gives remote attackers the ability to execute malicious code on the underlying servers.
The bug is present in Rails versions spanning the past six years and in default configurations gives hackers a simple and reliable way to pilfer database contents, run system commands, and cause websites to crash, according to Ben Murphy, one of the developers who has confirmed the vulnerability. As of last week, the framework was used by more than 240,000 websites, including Github, Hulu, and Basecamp, underscoring the seriousness of the threat.
"It is quite bad," Murphy told Ars. "An attack can send a request to any Ruby on Rails sever and then execute arbitrary commands. Even though it's complex, it's reliable, so it will work 100 percent of the time."
Monday, November 26, 2012
Spotted: The Web Won't Be Safe or Secure until We Break It
The Web Won't Be Safe or Secure until We Break It
Unless you've taken very particular precautions, assume every Web site you visit knows exactly who you are.Spotted: Browser Security Case Study: Appearances Can Be Deceiving
Browser Security Case Study: Appearances Can Be Deceiving
A discussion with Jeremiah Grossman, Ben Livshits, Rebecca Bace, and George Neville-NeilFriday, November 2, 2012
Find: Firefox gets strict about enforcement of HTTPS protection
Firefox gets strict about enforcement of HTTPS protection
Developers of Mozilla's Firefox browser are experimenting with a new security feature that connects to a specified set of websites only when presented with a cryptographic certificate validating the connection is secure.
A beta version of the open-source browser contains a list of sites known to deploy the HTTP Strict Transport Security mechanism that requires a browser to use the secure sockets layer or transport layer security protocols when communicating. HSTS is designed to provide an additional layer of security by mandating the channel is encrypted and the server has been authenticated using strong cryptography.
But there's a chicken-and-egg problem with HSTS. "Man-in-the-middle" attackers, who are positioned in between a browser and website, have the ability to prevent browsers from receiving the server code that enforces the additional protection. That makes it possible for HSTS to be circumvented by the very types of people the measure is designed to thwart.
Thursday, October 11, 2012
Find: Security breach briefly hijacks connections to Google.ie and Yahoo.ie
Security breach briefly hijacks connections to Google.ie and Yahoo.ie.
The outfit that manages Internet addresses for Ireland’s national .ie domain has temporarily taken some of its systems offline while officials investigate a security breach that temporarily hijacked the Irish websites for Google and Yahoo.
A short note on the homepage of the IE Domain Registry said the move followed a "security incident on Tuesday 9th October, involving two high profile .ie domains that has warranted further investigation and some precautionary actions on the part of the IEDR." Several independent Web posts, including those on Twitter and the site of a .ie domain registrar (Google cache here) identified the sites as Google.ie and Yahoo.ie. People trying to visit those addresses were briefly redirected to a fraudulent server as a result of "unauthorised access to one Registrar's account which resulted in the change to the DNS nameserver records for the two .ie domains," the latter blog post reported, citing IEDR CEO David Curtin.
Both of the affected sites, according to whois records, are managed by MarkMonitor, a company that protects the online brands of its customers. Sophos security expert Graham Cluley reported that the breach caused the IEDR to incorrectly point users to domain name system name servers at farahatz.net, which appear to be located in Indonesia.
Wednesday, September 5, 2012
Guest: Simon Brown of Lionheart Software Services will visit again on November 27
Folks,
Simon Brown of Lionheart Software Services will visit us again on November 27 to talk to us about web security.
Best,
Ben
Wednesday, August 15, 2012
Find: Improving Browser Security with CSP
Improving Browser Security with CSP
If you are using Firefox 4, you now have an extra layer of security when accessing mobile.twitter.com.
Over the past few weeks we've been testing a new security feature for our mobile site. It is called a Content Security Policy, or CSP. This policy is a standard developed by Mozilla that aims to thwart cross site scripting (XSS) attacks at their point of execution, the browser. The upcoming release of Firefox 4 implements CSP, and while the mobile site may not get a high volume of desktop browser traffic (the desktop users hitting that site typically have low bandwidth connections), it has given us an opportunity to test out a potentially powerful anti-XSS tool in a controlled setting.
CSP IN A NUTSHELL
In a typical XSS attack, the attacker injects arbitrary Javascript into a page, which is then executed by an end-user. When a website enables CSP, the browser ignores inline Javascript and only loads external assets from a set of whitelisted sites. Enabling CSP on our site was simply a matter of including the policy in the returned headers under the CSP defined key, 'X-Content-Security-Policy'.
The policy also contains a 'reporting URI' to which the browser sends JSON reports of any violations. This feature not only assists debugging of the CSP rules, it also has the potential to alert a site’s owner to emerging threats.
