Mozilla Fundraising: The Online Gear Store Closes March 31 |
https://mozfundraising.wpengine.com/the-online-gear-store-closes-march-31/
|
Yunier Jos'e Sosa V'azquez: Firefox OS ser'a el coraz'on de la nueva l'inea de televisores Ultra HD de Panasonic [ + Video ] |
Hace pocos d'ias, la firma japonesa Panasonic ha anunciado que Firefox OS seguir'a estando en sus Smart TVs y para este 2016 prepara nuevas sorpresas con su serie DX de televisores Ultra HD con dise~no vanguardista, 4K y novedosas tecnolog'ias al reproducir materiales audiovisuales.
Dise~no del nuevo Panasonic DX
Los nuevos televisores de Panasonic no s'olo llegan con la integraci'on de tecnolog'ias para ponerse al d'ia con los nuevos contenidos y experiencias, sino tambi'en poseen materiales premium para ofrecer un aspecto destacable en este mercado, donde la imagen y armon'ia que aportan al sal'on o habitaci'on, ya es parte primordial de estos dispositivos.
Con esta nueva actualizaci'on que Panasonic introducir'a un su serie DX, los usuarios disfrutar'an de una nueva v'ia para descubrir aplicaciones webs e instalarlas en su TV, entre las que podr'an encontrar juegos, noticias, tiempo y mucho m'as. Tambi'en se incluye la funcionalidad “Enviar al TV”, la cual permite f'acilmente compartir contenido Web desde Firefox para Android y un TV potenciado con Firefox OS.
Mozilla y Panasonic han estado colaborando desde 2014 para ofrecer a los consumidores experiencias de usuario optimizadas e intuitivas que les permitir'a disfrutar de los beneficios de la plataforma web abierta.
DEMO:
Fuente: The Mozilla Blog y Opini'on
|
Mozilla Addons Blog: Breakthroughs in the add-on review queues |
The last few months have been dense with big changes in the add-ons world. Just reading this blog and looking at all the new faces and posts should give you a good idea. Today I’d like to show you how these changes have affected the add-on review queues and what you can expect for the future.
These charts show the state of the review queues on a weekly basis, starting on Q4 last year:
The green area represents add-ons that have been waiting under 5 days, yellow between 5 and 10 days, and red over 10 days.
As you can see, we were doing pretty poorly in late 2015. We only had one admin reviewer, Andreas Wagner, whose attention was almost entirely focused on reviewing unlisted add-ons (not included in the charts). We already had a significant backlog of add-ons awaiting admin review, and during this time it got a lot worse. We were looking for new admin reviewers we could get on board as contractors, but most of our attention was focused on extension signing.
A few things happened that helped us get the review queues under control:
The review queues are now almost entirely in the green, which is fantastic (in fact, we’re all green in today’s report). However, it’s reasonable to have some skepticism, since we’ve been here before. We rely on a couple of very active volunteers who do the bulk of the reviews. And we will need to turn more of our attention to unlisted submissions soon (though not to the same extent as before).
So, what are we doing to maintain wait times that developers can rely on?
First, we have the staff additions I mentioned earlier. Having a stable admin team contributes greatly because we have a higher baseline even when volunteer activity drops. We also have another part-time opening that we will try to fill soon.
We’ve made some changes to the reviewer tools to encourage more participation from less-active reviewers. The review team has grown significantly in the past couple of months, and we receive new applications all the time. Are you interested in joining us? Please apply!
Finally, I think we’re past the big wave of submissions that happened due to the introduction of extension signing. But we do have a stable and steady increase in developer activity (which is good!).
We’d like to thank the add-on developer community for their immense patience during this time. We know it’s been rough and we’re very grateful that you stuck with us. We’ll keep working hard to make sure this becomes the standard.
https://blog.mozilla.org/addons/2016/03/04/breakthroughs-in-the-add-on-review-queues/
|
Karl Dubost: [worklog] HTML parsing, identifying mobile and other delicacies |
In the garden, narcissus have blossomed. Tune of the week: Love is all - Roger Glover and the butterfly ball.
Progress this week:
Today: 2016-03-05T10:58:24.148527 447 open issues ---------------------- needsinfo 11 needsdiagnosis 112 needscontact 90 contactready 83 sitewait 102 ----------------------
You are welcome to participate
(a selection of some of the bugs worked on this week).
toSource()
available only in FirefoxYou can now hot reload CSS and React components in devtools. To enable it, just flip the "devtools.loader.hotreload" pref and it should work without restarting, but you need to reopen any existing toolboxes.
width
for Firefox only.Otsukare!
|
Christian Heilmann: [German] Basta 2016 Keynote: Fahrvergn"ugen ohne Handbremse – IE ist tot, lang lebe das Web |
Die letzten drei Tage war ich in Darmstadt auf der BASTA Konferenz, um mich mit Leuten "uber den Tod von IE, dem Selbstverst"andnis eines immergr"unen Browsers in Windows, des Open Source releases von Chakra und Machine Learning mit Project Oxford zu unterhalten. Neben eines Interviews mit Entwickler TV und kiloweise tollem Essens habe ich dann auch die Keynote gehalten.
Die Slides zum runterladen gibt es auf Slideshare.
Den Screencast gibt es wie immer auf YouTube.
In den etwa 20 minuten habe ich die Basta Seite auseinandergenommen und einige Mythen der Webentwicklung zerlegt. Ausserdem gehts um Rolltreppen und japanische Toiletten.
|
Air Mozilla: Tech2Empower Cambodia Information Session |
On March 3rd, WAKE's co-founders will visit Mozilla SF to share ways women at Mozilla can get involved in their upcoming program, Tech2Empower – Cambodia....
https://air.mozilla.org/tech2empower-cambodia-information-session/
|
Chris H-C: Windows XP Firefox Users |
Speaking of fourteen-year-old technology: Windows XP.
Ah, Windows XP. The most-used Operating System until August, 2012. Released in October of 2001, it was an incredibly-popular upgrade to the previous champion, Windows 98 Second Edition.
It was so popular that Microsoft kept sending it security updates and assorted bugfixes up to April 8, 2014. That’s nearly twelve and a half years. That’s four and a half years after XPs true successor, Windows 7, was released. (We do not speak of Vista)
Windows 7 will end-of-life after only 10 years, in 2020. Windows 8 lost it after 3 (if you include 8.1, it will only last 9).
Why am I talking about it, almost two full years after even Microsoft stopped supporting Windows XP: the most long-supported of OSes from Redmond? Because people are still using it. And not just any people: Firefox users.
Roughly 12% of Firefox users on release and beta channels are running Windows XP. That’s almost as many as are using Windows 10 (15%) and almost double how many users we have on Mac (6.7%).
(For the record, Linux users on these two channels make up less than 1%)
[edit – oh, and please remember that the usual rules of Data Science apply: I’m only able to analyse what is being provided. So if a disproportionate number of Firefox users on, say, Linux aren’t reporting Telemetry on release or beta channels, they will be undercounted in the presented numbers]
“But… Who? I don’t know anyone who is using an operating system two years past its end-of-life.” you might be thinking. Well, this is called an “inherent bias”: just because it doesn’t happen to you doesn’t mean it isn’t happening.
Intrigued by this result (as I too know no one still running XP) I tried to find out what was different about the XP population as compared to the wider Firefox user base, and what was the same. I used a longitudinal dataset that we’re experimenting with internally, which is why all of my figures aren’t linked to analyses.
It might interest you to know that Windows XP users are more likely to have configured their Firefox to run in the Russian, Polish, or Spanish locales. They are less likely to have configured it to use the English or German locales.
Windows XP users are less centrally-located than other users. According to geo-ip lookups of users’ IP addresses when they submit Firefox Telemetry reports, nearly 18% of the Firefox user base is in the United States. That is a great degree of centralization and means Mozilla can get great “bang for its buck” with outreach programs that operate in the United States. A Windows XP Firefox user is far less likely to be in the United States or Germany, and is slightly less likely to be in Great Britain, France, or Japan. Instead, a Windows XP Firefox user is somewhat more likely to be in Russia, Poland, India, the Ukraine, Egypt, Spain, or Italy.
How engaged are Windows XP Firefox users? Maybe they only have it installed and running, but don’t actually use it much day-to-day.
A good predictor of engagement is having Firefox set as the default browser on a system, so a lower proportion of “default browser: Yes” for Windows XP users might signal lower engagement. However, the data shows that Windows XP Firefox users are more likely to have Firefox set as their system’s default browser (even accounting for how difficult it now is in Windows 10 to set non-Edge browsers to be the system default).
Another good predictor of engagement is having addons installed. Addons might also be a good signifier that a user chose Firefox because it offers, with its addons, a compelling feature that not just any other browser can match. Data says: Windows XP Firefox users are much more likely to have 0 addons installed than the Firefox users in general, so maybe the choice of browser was made for them? Maybe they don’t know about addons at all.
All these differences might make it easy to divide the user base into “us” and “them”. “They” are running an outdated OS. “They” make hardware acceleration development harder in Firefox.
But we are all similar in more respects than you realize. We are all just as likely to live in Canada, Mexico, Indonesia, Belgium, Portugal, South Africa, or any of the other dozens and dozens of countries where Firefox users live. We are all just as likely to be running an up-to-date version of release Firefox. We are all as likely to have a truly-ridiculous number of addons installed (13 or more).
And, most importantly, we all use Firefox to access the global resource that is the Web.
:chutten
Edit – I don’t have data to back up my assertion that “A good predictor of engagement is having Firefox set as the default browser on a system” and :dolske told me about an experiment Firefox ran where we just didn’t ask users to set us as their default browser. In the experiment, user retention and active hours did not decrease. Desktop users’ engagement is apparently unaffected by what browser is opened if you click on a link in another program.
https://chuttenblog.wordpress.com/2016/03/03/windows-xp-firefox-users/
|
The Mozilla Blog: Standing Up with Apple to Fight for Everyone’s Security |
Mozilla today is joining a coalition of technology companies, including Google, Nest Labs, Facebook, WhatsApp, Evernote, Snapchat and Microsoft, in filing an amicus brief in support of Apple’s position in its ongoing dispute with the Federal Bureau of Investigation. In our brief we are urging the district court not to force Apple to undo its own security protections to break into an iPhone.
Ultimately, companies like Mozilla are constantly striving to build more secure products. We make decisions every single day intended to protect our users. But those decisions affect all our users, which means Mozilla cannot weaken security for one user without effectively weakening it for everybody else. And it also means we cannot stand by as other companies are required to do so.
We are filing the amicus brief to help the court understand why it is dangerous to force technology companies to actively undermine their own security features. Opposing the FBI order is about taking a stand for public safety. It is the responsibility of technology companies to build as strong a product as possible to protect all users. We’ve already seen what weak security can do. We think users want more security, not less security. Tech companies should aspire to build “unhackable” products. With this precedent, we could all be told not to build secure products in the first place.
Security is critical to the continued evolution and growth of the Internet. It’s part of our mission to safeguard the Web, we consider it part of our job to take a stand on issues that threaten the health of the Internet.
https://blog.mozilla.org/blog/2016/03/03/standing-up-with-apple-to-fight-for-everyones-security/
|
Support.Mozilla.Org: What’s up with SUMO – 3rd March |
Hello, SUMO Nation!
How are you doing? March is here, and so are we with a new bunch of news and updates for you, hot off the SUMO-presses. Let’s get on with the show!
We salute you!
We hope you enjoyed the updates and are ready for more as March rolls its calendar out for all of us. Have you taken any fun photos that have SUMO or Mozilla as a theme that you could share? Let us know in the comments! SEE YOU ON WEDNESDAY AT OUR COMMUNITY MEETING!
https://blog.mozilla.org/sumo/2016/03/03/whats-up-with-sumo-3rd-march/
|
Air Mozilla: Web QA Weekly Meeting, 03 Mar 2016 |
This is our weekly gathering of Mozilla'a Web QA team filled with discussion on our current and future projects, ideas, demos, and fun facts.
|
Air Mozilla: Reps weekly, 03 Mar 2016 |
This is a weekly call with some of the Reps to discuss all matters about/affecting Reps and invite Reps to share their work with everyone.
|
Jorge Villalobos: Using WebExtensions to communicate between iframes |
After my presentation at FOSDEM, I was approached by developers who had a specific use case for an add-on. They asked which of our add-on technologies they should use to implement it, and whether it was practical to do. I knew it was doable, and I thought it would be an interesting programming exercise, so I gave it a shot.
Their problem concerns a government website that was particularly difficult to use and not very easy on the eyes. I think we all know the type. The add-on should make the site more manageable. So far, this is a straightforward content script. What makes this case trickier is that the site uses iframes to display parts of its contents, and the add-on should take the contents of those frames and embed them into the top document. My add-on will do this for a minimal test case, using the new WebExtensions API.
The first thing I need to work on this add-on is a page to test it with, so I created this one.
Test page. Note the green borders around the iframes.
It’s a very basic HTML page that has two iframes, one pointing to a page in the same domain and another one pointing to example.com. Using a different domain matters because certain iframe interactions are subject to same-origin policies and I wanted to ensure this add-on worked for all cases.
Other than the basic metadata, my manifest.json file has this:
"content_scripts": [
{
"matches": [
"http://xulforge.com/mozilla/iframe-example/*",
"http://example.com/*" ],
"all_frames": true,
"js": [ "scripts/flatten.js" ]
}
],
"background": {
"scripts": ["background.js"]
}
I declare the script using content_scripts
, giving it access to both domains involved. It’s important to set the all_frames
flag so that the content script is loaded into the internal frames of the page. Otherwise it is only loaded for top-level documents.
I also declare a background script, which will act as a message broker between the frames and the main document.
Messaging is the key element in this implementation. We need the top-level document to obtain the contents of the frames and then swap that content for the iframe nodes. Since different documents can be potentially running in different processes, message-passing is necessary. The frames will send their contents to the main document, through the background script:
if (window != window.top) {
// frame. Send message to background script.
browser.runtime.sendMessage(
{ "host" : window.location.hostname,
"body" : document.body.innerHTML });
}
The frames use sendMessage()
to pass the message to the background script. The message also includes the host so it’s easier to tell one frame from the other.
The background script is listening for these messages:
browser.runtime.onMessage.addListener(function(message, sender) {
and then forwards them to the main document:
browser.tabs.sendMessage(sender.tab.id, messages[0]);
Note that the sender
argument received from the frame message includes information of its tab of origin, which is necessary in order to us know where to send the message back. The sender
object also includes a frame ID, which could be useful in more complex scenarios.
Finally, the main document receives the message and swaps the frame for its contents:
browser.runtime.onMessage.addListener(function(message, sender) {
// ...
// XXX: message.body should be sanitized before injecting!
container.innerHTML = message.body;
// inject content from frame.
frame.parentNode.insertBefore(container, frame);
// remove frame.
frame.parentNode.removeChild(frame);
// ...
});
I’ll reiterate here that using innerHTML
in this way is very unsafe, since it opens the top document to XSS attacks. The contents of message.body
should be sanitized before they are injected.
Here it got interesting. I assumed that the content script for the main document would always load before the iframes, which would make managing the messages fairly easy, but that was not the case. During my testing, the content script on the first iframe loaded first. This means the background script in the extension needs to cache at least that first message until the message listener in the main document becomes available. The first message is lost if it’s forwarded right away.
To make the implementation close to correct, I have the background script wait for the 3 documents to be loaded before forwarding the messages to the main document:
if (message.loaded) {
// top document has loaded.
loaded = true;
} else {
// iframe has loaded.
messages.push(message);
}
if (loaded && messages.length == 2) {
// forward messages back to tab so the top window will use it.
browser.tabs.sendMessage(sender.tab.id, messages[0]);
browser.tabs.sendMessage(sender.tab.id, messages[1]);
// clear state.
loaded = false;
messages = [];
}
I set message.loaded
for the message coming from the main document. If that flag isn’t set, the message is coming from one of the iframes. When all 3 documents have reported themselves, both messages are forwarded to the main document, and the state is cleared for future loads.
This solution isn’t complete. It doesn’t take into account concurrent loads. This could be fixed with a map that is indexed by the sender tab id. It also doesn’t handle cases like when an iframe didn’t load, or when one of the iframe pages is loaded as the main document. These are all solvable problems but require more code than this simple example.
You can find the sources here and build the XPI for yourself. You can also download the built XPI here. Loading the test page with the add-on installed should look like this:
Note the entire contents are now visible, and the borders turn red to make it easier to tell the add-on worked.
That’s it! Hope this helps someone with their add-on. Let me know in the comments if you have any questions.
http://xulforge.com/blog/2016/03/using-webextensions-to-communicate-iframes/
|
Mozilla Cloud Services Blog: TTL Header Requirement Relaxed for WebPush |
A few weeks ago, we rolled out a version of the WebPush server that required a HTTP TTL
header to be included with each subscription update. A number of publishers reported issues with the sudden change, and we regret not properly notifying all parties.
We’re taking steps to solve that problem, including posting here and on Twitter.
To help make it easier for publishers and programmers to experiment with WebPush, we have temporarily relaxed the TTL requirement. If a recipient’s computer is actively connected, the server will accept and deliver a WebPush notification submitted without a HTTP TTL header. This is similar to the older behavior where updates would be accepted with a presumed TTL value of 0 (zero), because the server was able to immediately deliver the notification. If the recipient is not actively connected and the TTL header is missing, the server will return a HTTP status of 400 and the following body:
{“status”: 400, “errno”: 111, “message”: “Missing TTL Header, see: https://webpush-wg.github.io/webpush-protocol/#rfc.section.6.2”}
It’s our hope that this error is descriptive enough to help programmers understand what the error is and how to best resolve it. Of course, we’re always open to suggestions on how we can improve this.
Also, please note that we consider this a temporary fix. We prefer to stay as close to the standard as possible, and will eventually require a TTL header for all WebPush notifications. We’re keeping an eye on our error logs and once we see the number of incorrect calls fall below a certain percentage of the overall calls, we’ll announce the end of life of this temporary fix.
https://blog.mozilla.org/services/2016/03/03/ttl-header-requirement-relaxed-for-webpush/
|
Fabien Cazenave: Pivoting |
March 15 will be my last day at Phoxygen. In fact I’ve already stopped working there, as I’m taking all the PTO I had left.
It has been a very good experience and I enjoyed it a lot, but as Firefox OS got “pivoted” my work there has lost most of its purpose, and it’s time for me to move on.
Right now I’m back to my freelancer status, and I’m pivoting from Mozilla technologies to standard technologies that can last in the long term: as a XUL lover, I’m pivoting to WebExtensions and Electron.js for extension and desktop app development; as a Firefox OS developer, I’m pivoting to hybrid mobile apps; and as a web developer, I’m eager to use all the cool tricks I learned during the Firefox OS adventure on modern websites.
I’ve been a Mozillian for 10 years now, I’ve seen the project evolve a lot and I need some time to figure out how to contribute for the next 10 years. I’ll keep a close eye on B2G OS for sure! The main change is that I’m not looking for a Mozilla-related job any more: I’ll contribute just for the fun of it. ^^
Ready to explore new opportunities. Finally.
I have to say, it feels great. :-)
|
The Servo Blog: Servo and Summer of Code |
This summer, Servo is participating in both Google Summer of Code and Rails Girls Summer of Code.
If you have a passion for open source and want to work on a 3-month mentored Rust project in Servo (with a stipend), consider applying!
The Rails Girls Summer of Code project ideas can be found here, and the Google Summer of Code ideas are here. Applications need not be confined to these ideas; if you have something else you want to work on let us know.
Applications for Rails Girls Summer of Code are accepted from late February to March 15th. See here for eligibility. The coding period is from July to September.
Applications for Google Summer of Code are from 14-25th March. See here for eligibility. The coding period is from 23 May to 23 August.
Feel free to ask question on the #servo IRC channel on irc.mozilla.org, or email us at josh@joshmatthews.net or manishearth@gmail.com.
If you’re interested in Rust there are some other Rust projects out there too.
|
Air Mozilla: The Joy of Coding - Episode 47 |
mconley livehacks on real Firefox bugs while thinking aloud.
|
Niko Matsakis: Nice errors in LALRPOP |
For the last couple of weeks, my mornings have been occupied with a pretty serious revamping of LALRPOP’s error message output. I will probably wind up doing a series of blog posts about the internal details of how it works, but I wanted to write a little post to advertise this work.
Typically when you use an LR(1) parser generator, error messages tend
to be written in terms of the LR(1) state generation algorithm. They
use phrases like shift/reduce conflict
and talk about LR(1)
items. Ultimately, you have to do some clever thinking to relate the
error to your grammar, and then a bit more clever thinking to figure
out how you should adjust your grammar to make the problem go away.
While working on adapting the Rust grammar to LALRPOP, I
found I was wasting a lot of time trying to decrypt the error
messages, and I wanted to do something about it. This work
is the result.
An aside: It’s definitely worth citing Menhir as an inspiration, which is an awesome parser generator for OCaml. Menhir offers a lot of the same features that LALRPOP does, and in particular generates errors very similar to those I am talking about here.
What I’ve tried to do now in LALRPOP is to do that clever thinking for you, and instead present the error message in terms of your grammar. Perhaps even more importantly, I’ve also tried to identify common beginner problems and suggest solutions. Naturally this is a work-in-progress, but I’m already pretty excited with the current status, so I wanted to write up some examples of it in action.
Let’s start with an example of a truly ambiguous grammar. Imagine that I have this grammar for a simple calculator (in LALRPOP syntax, which I hope will be mostly self explanatory):
1 2 3 4 5 6 7 8 9 |
|
This grammar evaluates expressions like 1 + 2 * 3
and yields a
32-bit integer as the result. The problem is that this grammar is
quite ambiguous: it does not encode the precedence of the various
operators in any particular way. The older versions of LALRPOP gave
you a rather opaque error concerning shift/reduce conflicts. As of version
0.10, though, you get this (the actual output even uses ANSI colors,
if available):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
Much clearer, I’d say! And note, if you look at the last sentence, that LALRPOP is even able to diagnose that this an ambiguity specifically about precedence and refer you to the manual – now, if only I’d written the LALRPOP manual, we’d be all set.
I should mention that LALRPOP also reports several other errors, all of which are related to the precedence. For example, it will also report:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
The code for detecting precedence errors however doesn’t consider
errors between two distinct tokens (here, *
and +
), so you don’t
get a specific message, just a general note about ambiguity. This
seems like an area that would be nice to improve.
That last example was a case where the grammar was fundamentally ambiguous. But sometimes there are problems that have to do with how LR(1) parsing works; diagnosing these nicely is even more important, because they are less intuitive to the end user. Also, LALRPOP has several tools that can help make dealing with these problems easier, so where possible we’d really like to suggest these tools to users.
Let’s start with a grammar for parsing Java import declarations. Java’s import declarations have this form:
1 2 |
|
A first attempt at writing a grammar for them might look like this (in
this grammar, I gave all of the nonterminals the type ()
, so there
is no need for action code; this means that this grammar does not
build a parse tree, and so it can only be used to decide if the input
is legal Java or not):
1 2 3 4 5 6 7 8 9 10 |
|
Now, unlike before, this grammar is unambiguous. Nonetheless, if we try to run it through LALRPOP, we will get the following error:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
|
http://smallcultfollowing.com/babysteps/blog/2016/03/02/nice-errors-in-lalrpop/
|
Wladimir Palant: Why you should go with "secure by default" for your web application |
You probably heard about it, web applications are notoriously insecure. By now, most web developers seem to be aware of the security issues, yet vulnerabilities are more common than ever. Some people say, it’s simply because developers tend to make mistakes. Other people say (and I agree) that wrong tools are being used which allow developers to make mistakes.
Yes, SQL injection still isn’t dead. Every now and then some web application makes the news with an SQL injection vulnerability, some dynamically composed SQL query which goes like:
db.query('SELECT * FROM table WHERE date > ' + request['date'])
You can bet on some self-proclaimed expert declaring in the comments: “That programmer is a noob! How could he forget to escape the variable?” But of course he could because he is merely a human. Code reviews help but occasionally such mistakes slip through review as well. But it’s not just that, maybe request['date']
was indeed safe at some point, e.g. validation code elsewhere made sure it is a number. But then somebody decided to allow more values for it and nobody thought about adapting the code here.
So, are we stuck forever with SQL injection vulnerabilities? As long as we rely on manual escaping we likely will be, it is just too error-prone. Instead, we can establish a policy to use prepared statements consistently throughout the codebase. SQL queries should never be composed dynamically, parameters should be inserted via placeholders instead:
db.execute('SELECT * FROM table WHERE date > ?', request['date'])
Here, request['date']
is being passed in as parameter for the query, the database engine will take care of inserting and escaping it properly all by itself. We don’t need to do anything, so there is nothing we could forget!
Shell injection is very similar to SQL injection, it is also an issue that only exists because people keep using the wrong tools. Consider the following code:
exec('/usr/bin/gzip file -' + request['quality'])
This code expects request['quality']
to be a number, but what if it is something like 0; rm -rf /
? “Noob programmer, why did he forget to validate the parameter?” The answer is the same, human beings tend to forget things.
But the disaster here should be avoidable. All programming languages allow calling an application without going through the shell and specify the list of parameters explicitly:
exec(['/usr/bin/gzip', 'file', '-' + request['quality']])
What changed? Now '-' + request['quality']
is always a single parameter to the application, no matter what its value is. Allowing the user to pass in a random parameter to the application is still bad but usually it won’t cause any real harm.
But of course the side-effect is that all the nice stuff implemented by the shell won’t be available. Yes, you have to specify the full path to the application — there is no shell to locate it for you. Yes, you have to do variable expansion yourself. Yes, you have to route streams from one application to another “manually.” No, it’s not that hard and you don’t need the shell for that. On the bright side, your application won’t break when confronted with some unusual shell.
Bored? Sorry about that but we are coming to the interesting part now. Getting rid of Cross-Site Scripting is much harder, simply because there are so many different ways to write vulnerable code, some of which are not entirely obvious. But the classic scenario is still the following:
Your search for {{request.search}} produced no results.
You can probably guess by now that I’m not going to advice quickly escaping that variable before somebody notices. If the web application isn’t something entirely trivial there will always be some variable left unescaped. Luckily, there is a better solution: modern template frameworks are capable of escaping automatically! For example, Django templates escape by default, same goes for Ruby on Rails 3.0. Jinja2 supports autoescaping as well, sadly not by default however.
When using any of these template engines the code above will be perfectly safe, escaping will be performed automatically. Even better, they will automatically prevent double-escaping:
{% macro greeting(name) %}
Hey, {{name}}
{% endmacro %}
{{greeting(name) + postfix}}
In this example only the name
and postfix
variables will be escaped. The result of the macro on the other hand will be automatically marked as safe and won’t be escaped.
Hey, but what about JavaScript code? The templates won’t help you with inserting into JavaScript code and that’s why you just shouldn’t do it. I’m serious, don’t do it! When inserting into JavaScript code there is simply too much that can go wrong. For example, is JSON safe?
What if some value in your data is ""
? It simply closed your script
tag and created one of its own — all that while staying perfectly valid JSON code. The correct approach would take advantage of autoescaping:
{{data|json}}
Not only is this code safe now, the new JavaScript code is static and can be moved into a separate file. And this in turn allows you to enable Content Security Policy and disable all inline scripts. Huge win for security!
Want another example? Inline event handlers are something where escaping is notoriously hard to get right (see also “More complicated XSS” here).
It’s an attribute so autoescaping should do? No, it’s an attribute containing JavaScript code, so one would have to apply JavaScript-specific escapes before HTML escapes (yes, you have to do both and in that exact order). Rather than going down that rabbit hole, one can just use a regular attribute:
That’s it, now nothing can go wrong any more. And again, since your inline event handler is static code now, that’s a good opportunity to move it into a separate JavaScript file. Did I mention Content Security Policy already?
I could go on, e.g. about using secure DOM methods rather than innerHTML or about banning eval(). Way too often security issues in web applications are addressed by adding more checks and hoping that adding these won’t be forgotten anywhere. I consider this the wrong approach, there should be fewer checks. Instead, you should stick to tools that will enforce security by default. You shouldn’t have to do more work in order to make things secure, it should rather take extra effort to build a security vulnerability.
There is an additional benefit here. How does one tell that the web application is free of obvious XSS issues? Without autoescaping you would have to go through every single variable inserted into a template and verify that all of them are escaped properly. Autoescaping makes this tedious task unnecessary, all you need to check are the (hopefully few) cases where autoescaping has been explicitly disabled. Then you have to verify that no variables are being inserted into JavaScript code and you are already done.
https://palant.de/2016/03/02/why-you-should-go-with-secure-by-default-for-your-web-application
|
About:Community: Firefox 45 new contributors |
With the release of Firefox 45, we are pleased to welcome the 38 developers who contributed their first code change to Firefox in this release, 30 of whom were brand new volunteers! Please join us in thanking each of these diligent and enthusiastic individuals, and take a look at their contributions:
http://blog.mozilla.org/community/2016/03/02/firefox-45-new-contributors/
|