For xB Browser, for users running XeroBank, we’ve removed noscript and replaces it with SPP. That allows users to protect against cross-site scripting, and false certificates, without dealing with NoScript issues.
SPP can’t obviously stand for Site Pecurity Policy. It wouldn’t make sense (spelling and grammar aside) because SSP is not meant and not going to replace NoScript anytime soon. The SSP we know does not allow “users to protect against” anything, it just allows compliant web sites to protect their own users (which is great, anyway).
So, any hint about this SPP supposed NoScript killer?
However Mozilla developers are working around the clock, and there’s already a patch being privately tested. All the information publicly available so far is that this vulnerability allows a malicious web page to trigger the execution of arbitrary code on the client side, and affects Firefox 2, 3 and likely all the products based on the same rendering engines. Technical details and exploitation proof of concepts are being kept private by Tipping Point as well until the patch is shipped, therefore Mozilla users should be relatively safe: after all we can be 99.99% sure every browser out there is vulnerable to something; we just hope that the bad guys don’t know the details yet.
I can add that, even in this case, NoScript users are the safest.
IBM® Database Connectivity for JavaScript™ is middleware that enables Web clients to directly access server-side relational data without compromising enterprise security.
“Directly access” without compromising “enterprise security”, yeah…
On the client, IBM Database Connectivity for JavaScript consists of a JavaScript API and library that can be used by Web applications without special browser plug-ins. On the server, the IBM Database Connectivity for JavaScript gateway, written in PHP, is an adaptor layer that mediates between IBM Database Connectivity for JavaScript and relational databases and provides functions such as operation forwarding and security. Web 2.0 applications can thus use IBM Database Connectivity for JavaScript to access relational data as a first-class construct instead of through ad hoc protocols.
Before you start wondering (like I did) what “operation forwarding” and “security” mean in this context, I’ll tell you since I bothered to read the source code: it’s just a thin layer with a JDBC-like API which allows JavaScript code to compose and submit SQL statements from the client side!
Security, if any, needs to be enforced at the database level, and access credentials are sent from the client side as well.
IBM Database Connectivity for JavaScript supports the trend for Web applications to be dynamically composed in a Web browser — so-called “Web 2.0″ applications — instead of being completely composed on the server (”Web 1.0″).
First “enterprise”, now “Web 2.0″…
IBM Database Connectivity for JavaScript is specifically geared toward enabling the potential Web 2.0 benefits of increased application responsiveness and the ability to flexibly combine information from various sources on the client. Web 2.0 access to server-side data, however, is currently characterized by Representational State Transfer (REST)-like APIs, which are typically application specific.
Bah, those old-fashioned resource mappings which (try to) expose only the data subsets relevant to the application front-end…
But now we can unleash the full power of SQL: free queries to all our databases for everyone in the fantastic world of Web 2.0!
ODBC is powerful — allowing any SQL statement to be executed — and simple, in the sense that developers are required to understand only a few abstractions. IBM Database Connectivity for JavaScript can be thought of as an “ODBC for Web clients,” enabling Web developers to benefit from a general-purpose API for accessing relational data.
Great work IBM! Now please convince some of your many banking customers to deploy this fantastic technology on their Internet-facing web servers, and we’ll be happy to “benefit from a general purpose API for accessing relational data” directly from Firebug, thanks!
Not a big deal, really, if you consider FlashBlock a “noise reducer”: it does a great job, in facts, working almost always.
A bit more worrisome, though, if you used to believe FlashBlock could improve your security against Flashvulnerabilities. Your next surprise video star may be way more malicious than Trojan.SWF.Astley…
To be fair, you would be in good company:
Slashdot, whose “flashblock” tag is attached to all the most recent Flash security horror stories
US-CERT (United States Computer Emergency Readiness Team)
If they just looked at FlashBlock’s FAQ, they would have found that the word “security” is never mentioned: a testament both to the good faith of the developers, who honestly advertise FlashBlock as an excellent annoyance blocker rather than a security enhancement, and to the superficiality of some advices.
Dancho is especially inexcusable, since he’s the only one forgetting to mention NoScript, which features similar flash-blocking capabilities but, being developed with security as its main focus, is immune from this and other possible circumventions and, more important, would regard even the most exotic unblockable edge case as a serious bug to be fixed as soon as possible.
A couple of months ago, Brandon Sterne of the Mozilla Security Team asked me some questions about NoScript’s internals, because he was developing a Firefox add-on which involved selective script-blocking.
A Site Security Policy is defined by the website administrator and communicated to the web browser as a set of special “X-SSP-…” HTTP headers either attached to the affected content or sent in response to a “discovery” HEAD request:
X-SSP-Script-Source specifies a deny/allow list of hosts which are allowed to run scripts.
If this header is sent, no embedded script is allowed to run, and only included scripts whose sources match the rules are executed. This is an effective anti-XSS countermeasure, and could be extremely useful for so called “Web 2.0″ sites featuring user-generated rich content.
X-SSP-Request-Source lists the hosts which can or cannot send HTTP requests to a certain resource, and the “acceptable” HTTP verbs.
This can help enforcing referrer-based checks against CSRF attacks which work even if user chooses to omit or spoof the Referer header for privacy reasons, and mitigating verb-tamperingattacks when used to “enhance” CSRF.
X-SSP-Request-Target limits the destinations of requests originated by the current page.
This may help mitigating data-leakage outcomes of a successful XSS attack, e.g. by preventing authentication tokens from being logged to remote hosts, but also avoiding the page to be used as a platform for CSRF attacks and blocking inclusion of unwanted 3rd party content.
X-SSP-Report-URI declares an URL where policy violation attempts should be logged by the browser.
If you want to start applying these restrictions to your web content, you’ll find a detailed yet simple reference with examples on Brandon’s project web site.
Implementing a Site Security Policy cannot surrogate web developers’ security awareness and best practices, but it’s nonetheless a big step forward in making a website safer for its users.
Obviously enough, to be generally effective this technology still needs to be evangelized to administrators and coders, correctly deployed and supported in a consistent cross-browser fashion. But as soon as it gets built in our favourite browser and we begin to see badges like “Browsing this site is safer with Firefox”, we can hope other vendors to join making the Web a safer place.
