RETURN $ecure;

Security, Technology and Life

Posts Tagged ‘Opera

UserJS URL Sanitizing

with 5 comments

I was reading a post by RSnake over at Darkreading and got to thinking about client-side security.  There seems to be very little we can do against most things for the average user. NoScript is fine for a tech-minded individual, but the average user will probably forget about it and wonder why a site is now missing functionality.

So what do you think of some javascript that could check the URL for typically bad characters(since JS can easily find html-entities/url encoding/etc.)  and then sanitize them somehow? This could mean removing them or properly entifying them. Sure it’s fine. But even Greasemonkey scripts on run after a page is loaded. How could we do this?  Let’s take a look at UserJS in Opera.

User JavaScript is loaded and executed as if it were a part of the page that you visit. It is run immediately before the first script on the page. If the page does not contain any scripts of its own, User JavaScript will be executed immediately before the page is about to complete loading. It is usually run before the DOM for the page has been completed. (Note that this does not apply to Greasemonkey scripts. “….”User JavaScript will not be loaded on pages accessed using the opera: protocol. By default, it is also not loaded on pages accessed using the https: protocol.

Oh! So it should run before any other script is run. This is good. We can check to see if a script was injected, then proceed to remove it. But what if the injection is inside javascript? It will be hard to tell if it’s valid or not. Well since we are using UserJS already, let’s look at the UserJSEvent object and event listeners.

if( location.hostname.indexOf('example.com') != -1 ) {
  window.opera.addEventListener('BeforeScript',
   function (e) {
       e.element.text = e.element.text.replace(/!=\s*null/,'');
    },
    false
  );
}

BeforeScript
Fired before a SCRIPT element is executed. The script element is available as the element attribute of the UserJSEvent. The content of the script is available as the text property of the script element, and is also writable:

UserJSEvent.element.text = UserJSEvent.element.text.replace(/!=\s*null/,”)

So with this, we can check the text of a script object before it fires to sanitize it, which we could set to do only if it contains echoed content. Just a note that this isn’t restricted to off-site JS like it can be in some browsers. UserJS has full access to remote files accessed via script src even before it executes.  The hardest part is obviously sanitizing, but with some work I don’t see it being a huge issue for some basic XSS protection on the client-side.  I’m sure you could even expand it to  search all scripts for things that are commonly malicious like sending document.cookie somewhere to help protect against persistent XSS.

Anyways, I’d love to hear feedback on this idea before I go run off and make it.

Advertisements

Written by Rodney G

11/21/2007 at 6:03 pm

Posted in Security

Tagged with , , , , ,

Opera to support HttpOnly

with 3 comments

Heya. I haven’t blogged in awhile but I do want to start getting back into it.

So, we’ll start with something small.

I read this article the other day about updates coming to Opera in 9.5 and was pleasantly suprised to read that it will support HttpOnly cookies. Now, if you don’t know what that is I’ll give a quick run-down. Normally, cookies are able to be accessed through scripts with things like document.cookie in JavaScript. Along with the normal cookie header, in Set-Cookie you can set it to HttpOnly. This means the cookie cannot normally be read from means other than sending it in an Http Request. This slightly mitigates using XSS to steal credentials as you can no longer read the cookie with JavaScript and send it out, but obviously doesn’t stop phishing via any means. Many sites do use HttpOnly cookies but currently,  only Internet Explorer supports it. If you use a browser that doesn’t support it,  it simply is downgraded to a normal cookie. To be fair, Firefox 3 is planned to have support for it as well but it seems 9.5 will be out before FF3. At any rate, while this won’t stop XSS, it basically eliminates the risk of cookie theft.

Just remember though, cookie theft isn’t the only credentials that can be stolen with XSS or other methods. ‘Dynamic’ phishing methods that don’t rely on a third-party site are still somewhat hard to detect and should be watched out for.

Written by Rodney G

05/10/2007 at 1:37 pm

Posted in Uncategorized

Tagged with , , ,

A thousand dollars and a fancy phone.

with one comment

 There was an article going around on a few sites today about Acunetix stating that 70% of websites are at immediate risk of being breached. Soon after, Joe Snyder not only disputed this claim, but bet Acunetix 1000$ they couldn’t compromise 3 out of 10 sites. I could use a thousand bucks and I bet even randomly selected I could get at least 5 out of 10 sites. RSnake wrote a post with a bit more info.

Also, Iwatsu selected Opera for use in their new VoIP phone. From the press release,

PRECOT (Premium Communication Tool) is a next generation solution over a broadband IP connection for the enterprise market. With Opera, PRECOT users can access Web mail or any Web page from the convenience of their screen phones.

It will also have phone to tag support, which basically turns any numbers formatted like a phone number into a link, when it’s clicked the phone will call it. Pretty nifty stuff.

Too bad I dislike phones.

Written by Rodney G

02/14/2007 at 10:33 am

Posted in Uncategorized

Tagged with , ,