Security

Back to school – Security

Another week, another data breach

As we develop web sites and APIs, we need to keep security in mind. I know this is obvious, but it is also something often overlooked. It is not glamorous. It is not something that has perceived value by many in management. That is, until there is a security breach and associated bad publicity. Security vulnerabilities come in many different guises. Many have one thing in common – they were addressed many years ago. Yet, we often keep making the same mistakes on sites. We know how to fix many of these. We simply have not forced the idea that security must be incorporated into all our work processes. Just look at the OWASP top 10 vulnerabilities. Sure there are differences between the 2013 and 2017 versions, but there are many similarities as well. Cross site scripting remains a threat (as does SQL injection and many other vulnerabilities).

Web application security matters

We all need to be thinking about security as we develop web applications. However, those teaching application development need to stress this in every project assigned. Unless security becomes ingrained in our application development process we will continue to repeat the mistakes of the past. And. Data breaches will continue.

We can (and must) do better

As an educator, I often stress the idea – “trust your visitors, but never trust their input.” For every form submission, one should be thinking of sanitizing input. As a teacher, do not accept an assignment as complete unless there has been both client and server side validation on all input fields (even selection lists). After all, one can easily disable JavaScript in the browser or modify the input stream so additional information can be sent to the server.

If information submitted from a form is going to be added to a database, one should sanitize all the information. One should also use appropriate measures (such as stored procedures or similar) to prevent uploads of malicious code.

We should always only collect the minimum information needed to complete a given task. If there is no need to collect physical mailing address information, don’t (this is just one example). Obviously, if you are collecting credit card information, don’t offer to store the card details, only keep the transaction information.

Whether you are teaching web page development using a tool like Dreamweaver or teaching using tools like Atom or Brackets, it is important to keep security in mind with every assignment. If you are using a framework (such as Vue.js on the client side or Laravel for PHP on the server), make certain you take advantage of security as well. Test your applications against known vulnerabilities before deploying them (or before you accept an assignment as a teacher).

Use SSL where appropriate

If you are asking for login information, make certain the information is sent encrypted. One can easily employ Let’s Encrypt SSL certificates these days (or employ similar technologies). Use them. Never send credentials in plain text over the Internet. Use secure FTP (or other secure file transfers).

For those teaching these technologies, if you are not certain how to incorporate security into your assignments, please reach out to us in the comments. We will be glad to help.

These days, one can not be paranoid enough.

We look forward to your comments.

Best always,

Mark DuBois
Community evangelist and Executive Director
Web Professionals

The post Back to school – Security appeared first on Web Professionals.

View full post on Web Professional Minute

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

How Cyber Security is changing the web design industry

Today’s article is from our member Julia Eudy. Julia – Many thanks for writing this article and providing your insights.

When I think of the industry of web design, I think of the many talented people responsible for populating the internet with information over the past couple of decades. But our job is never done! From continual refinement of responsive design, to developing content worthy of Google’s latest search strategy; our jobs as designers and web managers is an ever-evolving landscape. In today’s market it is essential to stay current with technology and the threats targeting those we serve and those who search online. Without constant awareness and action by our peers in technology, cybercriminals will continue to challenge our time, patience, and livelihood.

Websites have become Key Point of Attack for Cybercriminals

While many believe that email phishing is a key entry point for most cyber criminals, it has become apparent that they are often using an unsuspecting website to hide their activity of malware designed collect valid emails and launch other criminal schemes. While some argue that nothing is hack-proof; content management systems built on open-source code have enabled the unsecure environment we now reside. It goes without saying that sharing code saves time; but is it worth the longer-term cost?

Let’s explore the leading CMS platform, WordPress. It is an easy-to-use interface making it popular among novice developers and DIY professionals, but it is often a prime target of hackers who specifically build robotic scripts designed to quickly search through the openly published source files looking for vulnerabilities. Technical web designers (those who know how to customize the code and apply advanced security settings) understand that keeping current on updates and effectively managing a recovery plan for the sites you have created has become a time-consuming task and one that is raising the overall cost of website management. However, the millions without some technical skillset, have likely already become an unsuspecting victim to one of the many ongoing threats facing the WordPress community.

A prime example of how open-source code created a breeding ground for a cyberattack happened in early 2017 when one of 20 hacking groups launched a digital turf war on WordPress by discovering a flaw found in their REST API script. A wide-spread attack impacted roughly 1.5 million pages of WordPress sites1 across 39,000 unique domains in a matter of days as reported by security plugin developers WordFence and Sucuri. Keep in mind that only 1.5 million of the 24 billion pages running WordPress2 are protected by these firewall applications.

Insurance Companies are Looking at Who to Blame for the Increase in Commercial Claims

From the outside looking in, the internet landscape is under attack, but who is to blame? This is a question many insurance companies are beginning to ask3 as their costs to cover cyber-attacks on commercial policies continue to rise.

Looking at a big picture, here are some general facts to consider…

  • According to the Small Business Administration, there are approximately 28 million small businesses in America which account for approximately 54% of all sales in the country. 4
  • In a 2017 report by Kaspersky Lab, the average cost for a data breach against a small and medium-sized business in North America was $117,000.5
  • An article published in 2017 by INC Magazine, referenced a presentation made at the NASDAQ by Michael Kaiser, the Executive Director of the National Cyber Security Alliance, who stressed concerns about the attack on Small Business and that such attacks are expected to continually rise because of their (the small business professional’s) lack of awareness of the pending risks.6
  • A 2016 study performed by Ponemon Institute LLC and Keeper Security revealed that the number one type of cyber attack targeting small and medium sized businesses was through a web-based attack with the web server being the most vulnerable entry point.7
  • That same study by Ponemon Instutute cited “negligent employees or contractors” as the root cause of the data breach. 7

So, I ask you, when the Insurance companies follow the facts, who do you think they will turn to recover their loss?

  • Will it be the random person who pointed out their vulnerability by successfully holding their web presence ransom? – likely not. That person is too difficult for them to track.
  • Will they blame the contractor who their customer hired to create their website? – Yes!

In recent conversations I’ve had with insurance professionals, one question asked was, “Should web designers have an ethical obligation to inform an untechnical customer of the risks involved with having a website?” As a technology professional, I agreed that they should and most likely do, but it is often the customer who elects to not add to their expenses for proper technical support. Their reply – “Ok, show me the proof and we go back to our customer!”
Most web managers are aware that being hack-proof is near impossible to achieve; however, as web professionals we are hopefully more aware and have taken necessary precautions to defend our livelihood. Contracts, authorized “opt-out” forms proving we’ve informed the customer of the risks, and building trusted relationships with supporting contractors are just a few first places to start; but having our own policies to cover mistakes and cyber threats should also be considered.

Like our other certifications, we are exploring resources necessary to develop a comprehensive training and security certification to help web developers stay current with different types cyber threats that they may encounter. This certification would identify specific areas that are being targeted and give the opportunity for continued training opportunities to learn more or improve your skills in specific areas. This certification would also classify you as a Cyber Certified Web Professional which will identify to those seeking a web services provider that you have participated in training that is designed to reduce their web-based risks.

If you are interested in learning more about this certification and the time schedule for training and certification release, please contact us and let us know your thoughts.

CITATIONS:

  1.  1.5 million pages of WordPress sites
  2. 24 billion pages running WordPress
  3. Insurance
  4. SBA
  5. Kaspersky Lab
  6. INC Magazine Article
  7. Ponemon Institute/Keeper Security Study

Author Bio

Julia Eudy is a Technology Consultant with specialties in Online Marketing, Web Design and Cyber Security. She teaches Content Management Systems (WordPress) and Social Media Marketing at St. Charles Community College in Cottleville, MO, in addition to managing a small Online Marketing firm (Golden Services Group) that focuses on online marketing solutions for small-medium sized businesses. Additionally, she is working with a group of professionals to create a training program designed to inspire K-12 students to pursue careers in technology and cyber security.

The post How Cyber Security is changing the web design industry appeared first on Web Professionals.

View full post on Web Professional Minute

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

February security review

We are now midway through the second month of the new year. This should be a good time for web professionals to review and update their individual security practices. Do your daily practices keep you secure? Are you certain? It is easy to to become complacent with our practices, credentials and equipment. This might be a good time to review individual security fundamentals.

Is it time to review your security practices?

We have all seen the examples where passwords are taped to a monitor or under a keyboard. We know not to do that. But do we periodically stop to consider our daily practices and how they affect security? This might be a good time to ask ourselves the following questions…

Best practices

With respect to passwords – are yours long and complex? Do you use passphrases? Are they impossible to guess? Do you use a different password on each site? Do you keep your passwords in a vault? Do you change your passwords from time to time?

Do you use two factor authentication (because passwords alone are no longer enough)?

When you are traveling – do you use a VPN (if you must connect to a public network – such as a hotel or airport)? Do you keep your phone and tablet backed up? Do you have the ability to track a device (in the event you lose it)? Do you have the ability to remotely wipe said device (again if it is lost or stolen)?

Do you routinely update your applications and operating system? Do you do this on your phone and tablet as well?

Additionally, do you do a factory reset on devices before you dispose of them (or recycle them)? Do you confirm that all data has really been erased from the device?

Hopefully you have been able to answer in the affirmative to all the above questions. If not, this might be a good time to rethink your practices. This also might be a good time to discuss these topics with colleagues and clients.

Resources

We have found the following resources helpful (you might want to share some of these with your colleagues and clients as well). All are links to the SANS website. I am a reviewer of their OUCH newsletter. These are provided because they can also be easily shared with colleagues and clients. Hopefully you find them useful.

What other security practices do you employ periodically? Care to share stories of “best practices” and how they helped (either personally or a client)?

As always, we look forward to your comments.

Best always,
Mark DuBois
Executive Director and Community Evangelist

The post February security review appeared first on Web Professionals.

View full post on Web Professional Minute

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Web Professional Trends 2016 – Web Security

2016 – The more things change, the more they remain the same. Web security is and will continue to make the news in 2016 (and that is not a good thing). Yes, we will continue to see social engineering (never under-estimate the social engineering power of a clipboard; never forget some people will reveal their password for a pen). We will continue to see phishing (and other forms of malicious email). Malware will continue to be an issue (along with ransomware and other trends). All this has been news for the past decade. And it will not go away in 2016.

My intent is to focus on what is new, why this topic is vitally important to Web professionals, what you need to know to protect yourself and others including your clients and how our community could improve the future of Web security and the sustainability of our profession.

What’s new in Web security issues

  • What is new in 2016 is greater reliance on the Internet of Things (IoT). Personally, I have more and more devices connected to my home network. I am not alone. I know these devices rely on HTML, CSS, and JavaScript. I also know that security seems to be an afterthought on many of these devices.
  • Wearable technology is another area which is growing (and which often relies on the same web technologies – HTML, CSS, JS). We should have security concerns about these devices as well. Specifically, they often touch other devices (such as our smartphones with a wealth of data). Security breaches can go well beyond a watch or fitness device.

What does this mean for the Web professional?

We tend to rely more and more on the cloud for all sorts of activities. Personally, I have spent a fair amount of time investigating technologies like Docker Containers. What I struggle with is how secure many of these repositories are (we have to depend on others as we do not see the underlying infrastructure). We also have to make the assumption that the items we use from repositories are free of malware.

What you need to know:

  • As web professionals, we need to remain vigilant and monitor our applications for breaches and any unusual events.
  • We also need to stay on top of emerging technologies. When we work with vendors and implement solutions, we need to question how much attention has been given to security.
  • We need to keep up to date on latest trends and always make our code as secure as possible. For example, I stress to my students they should always trust visitors to their websites, but never trust their input. We should already be in the habit of sanitizing any data provided by a web site visitor. Yes, we still read about SQL injection attacks and Cross Site Scripting. We have known how to defend against these sorts of attacks for many years. Yet, the attacks still happen.
  • We need to audit our existing code to confirm that we do defend against these sorts of attack vectors.
  • Always make an effort to confirm what you are installing is secure (and free of malicious code).
  • New attack vectors emerge all the time. We need to understand these threats and the implications on our existing code.
  • We need to be ready, remain vigilant, and keep up to date on emerging threats.
  • When you install any new device, make certain you have an idea of how vulnerable it is to attack (and where the attacks are likely to come from).
  • Continue to educate your clients on the dangers of these sorts of attacks.

We’re hopeful that you find our resources helpful. By aligning with a professional association we aim to support you in staying current with trends and to bring you the informational resources to succeed. As a professional organization, we also help educate. We can help you network with others. 2016 will be a combination of old attacks and new ones. We help each other through our network. Check out the other Web professional trends and if you’re not already a subscriber sign up. Future posts will include more on sustainability, what this means for the future of web professional, web-centric education and more in depth tutorials on web design, web development (including web security) and web business trends.

Best always,
Mark DuBois, Community Evangelist and Director of Education

The post Web Professional Trends 2016 – Web Security appeared first on Web Professionals.

View full post on Web Professional Minute

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Implementing Content Security Policy

The add-ons team recently completed work to enable Content Security Policy (CSP) on addons.mozilla.org (AMO). This article is intended to cover the basics of implementing CSP, as well as highlighting some of the issues that we ran into implementing CSP on AMO.

What is Content Security Policy?

Content Security Policy (CSP) is a security standard introduced to help prevent cross-site scripting (XSS) and other content injection attacks. It achieves this by restricting the sources of content loaded by the user agent to those only allowed by the site operator.

The policy is implemented via headers that are sent with the server response. From there, it’s up to supporting user agents to take that policy and actively block policy violations as they are detected.

Why is it needed?

CSP is another layer of defense to help protect users from a variety of attack vectors such as XSS and other forms of content injection attacks. While it’s not a silver bullet, it does help make it considerably more difficult for an attacker to inject content and exfiltrate data.

Building websites securely is difficult. Even if you know general web security best practices it’s still incredibly easy to overlook something or unwittingly introduce a security hole in an otherwise secure site.

CSP works by restricting the origins that active and passive content can be loaded from. It can additionally restrict certain aspects of active content such as the execution of inline JavaScript, and the use of eval().

Implementing CSP

To implement CSP, you must define lists of allowed origins for the all of the types of resources that your site utilizes. For example, if you have a simple site that needs to load scripts, stylesheets, and images hosted locally, as well as from the jQuery library from their CDN, you could go with:

Content-Security-Policy:
default-src 'self';
script-src 'self' https://code.jquery.com;

In the example above, Content-Security-Policy is the HTTP header. You can also specify Content-Security-Policy-Report-Only, which means that the user agent will report errors but not actively block anything. While you’re testing a new policy, this is a useful feature to enable.

For script-src, we have to also explicitly list 'self' because if you define a directive then it no longer inherits from default-src.

It’s very important to always define default-src. Otherwise, the directives will default to allowing all resources. Because we have default-src 'self', this means that images served from the site’s domain will also be allowed.

default-src is a special directive that source directives will fall back to if they aren’t configured. However, the following directives don’t inherit from default-src, so be aware of this and remember that not setting them to anything means they will either be unset or use the browser’s default settings:

  • base-uri
  • form-action
  • frame-ancestors
  • plugin-types
  • report-uri
  • sandbox

Setting 'self' as default-src is generally safe, because you control your own domain. However if you really want to default to locking things down more tightly you could use default-src 'none' and explicitly list all known resource types. Given the example above, this would result in a policy that looks like:

Content-Security-Policy:
default-src 'none';
img-src 'self';
script-src 'self' https://code.jquery.com;
style-src 'self';
If you rely on prefetching, you might encounter problems with default-src 'none'. On AMO, we discovered that browser prefetching in Firefox will not be identified as a specific content type, therefore falling back to default-src. If default-src doesn’t cover the origin involved, the prefetched resource will be blocked. There’s a bug open with additional information on this issue.

Dealing with inline script

CSP by default doesn’t allow inline JavaScript unless you explicitly allow it. This means that you need to remove the following:

  • <script> blocks in the page
  • DOM event handlers in HTML e.g: onclick
  • javascript: pseudo protocol.

If you do need to allow it then CSP provides a way to do it safely through the use of the nonce-source or hash-source directives, which allow specific blocks of content to be executed. You can opt out of this protection through the use of ‘unsafe-inline’ in the script-src directive, but this is strongly discouraged as it opens up your site to XSS attacks.

For additional information on nonce-source and hash-source, see CSP for the web we have.

Dealing with eval()

CSP also blocks dynamic script execution such as:

  • eval()
  • A string used as the first argument to setTimeout / setInterval
  • new Function() constructor

If you need this enabled you can use 'unsafe-eval' but again this is not recommended as it is easy for untrusted code to sneak into eval blocks.

On AMO, we found a lot of library code that used eval and new Function, and this was the part of CSP implementation that took the most time to fix. For example, we had underscore templates that used new Function. Fixing these required us to move to pre-compiled templates.

Dealing with cascading stylesheets (CSS)

CSP defaults to not allowing:

  • <style> blocks
  • style attributes in HTML

This was a bit more of a problem for us. Lots of libraries use style attributes in HTML snippets added to the page with JavaScript and we had a sprinkling of style attributes directly in HTML templates.

It’s worth mentioning that if style properties are updated via JavaScript directly, then you won’t have a problem. For example, jQuery’s css() method is fine because it updates style properties directly under the covers. However, you can’t use style="background: red" in a block of HTML added by JS.

This can be a bit confusing because in the Firefox inspector, style properties that have been added via JavaScript look identical to style attributes in HTML.

As before, you can use the nonce-source and hash-source directives if you need a controlled approach to allow select pieces of inline CSS.

You’re probably thinking, “This is CSS, what’s the risk?” There are various clever ways that CSS can be used to exfiltrate data from a site. For example, with attribute selectors and background images, you can brute force and exfiltrate attribute sensitive data such as CSRF tokens. For more information on this and other more advanced attack vectors through CSS see XSS (No, the _other ‘S’).

Using 'unsafe-inline' for style-src is not recommended, but it’s a case of balancing the risks against the number of changes that would be necessary to eliminate inline styles.

Reporting

It’s a good idea to set the report-uri directive and point it somewhere to collect JSON reports of CSP violations. As CSP doesn’t currently coalesce error reports, a single page with multiple errors will result in multiple reports to your reporting endpoint. If you run a site with a large audience, that endpoint can receive a significant amount of traffic.

In addition to reports triggered by actual violations, you’ll also find that many add-ons and browser extensions can cause CSP violations. The net result is a lot of noise: Having something that allows for filtering on the incoming data is highly recommended.

Testing

Once you have created your initial policy, the next step is to test it and fix any missing origins. If you run a large site, you may be surprised by the number of sources that you are pulling resources from. Running the site with CSP in report-only mode allows you to catch problems via the console and CSP reports before they actively block things.

Once everyone has confirmed that there’s nothing being blocked erroneously, it’s time to enforce the policy. From there on, it’s just a case of watching out for anything that was missed and keeping the policy up to date with browser support for some of the newer features in CSP.

Implementing

After you have settled upon a policy that works properly, your next step is to configure your system to deliver the CSP directives. Implementing this varies widely depending on your choice of web server software, but it should generally look like this:

# Enable CSP in Apache
Header set Content-Security-Policy "default-src 'none'; img-src 'self';
    script-src 'self' https://code.jquery.com; style-src 'self'"
# Enable CSP in nginx
add_header Content-Security-Policy "default-src 'none'; img-src 'self';
    script-src 'self' https://code.jquery.com; style-src 'self'";

If your service provider doesn’t offer control over your web server’s configuration, don’t panic! You can still enable CSP through the use of meta tags. Simply have your meta tag be the first tag inside <head>:

<!-- Enable CSP inside the page's HTML -->
<head>
    <meta http-equiv="Content-Security-Policy" content="default-src 'none'; img-src 'self';
          script-src 'self' https://code.jquery.com; style-src 'self'">
</head>

Our final implementation

Given that AMO is an older and extremely complex site, you’re probably curious as to what our final policy ended up looking like:

Content-Security-Policy:
default-src 'self';
connect-src 'self' https://sentry.prod.mozaws.net;
font-src 'self' https://addons.cdn.mozilla.net;
frame-src 'self' https://ic.paypal.com https://paypal.com
https://www.google.com/recaptcha/ https://www.paypal.com;
img-src 'self' data: blob: https://www.paypal.com https://ssl.google-analytics.com
https://addons.cdn.mozilla.net https://static.addons.mozilla.net
https://ssl.gstatic.com/ https://sentry.prod.mozaws.net;
media-src https://videos.cdn.mozilla.net;
object-src 'none';
script-src 'self' https://addons.mozilla.org
https://www.paypalobjects.com https://apis.google.com
https://www.google.com/recaptcha/ https://www.gstatic.com/recaptcha/
https://ssl.google-analytics.com https://addons.cdn.mozilla.net;
style-src 'self' 'unsafe-inline' https://addons.cdn.mozilla.net;
report-uri /__cspreport__

Wow! As you can imagine, quite a lot of testing went into discovering the myriad resources that AMO utilizes.

In Summary

The older your site is, the more work it will take to set and adhere to a reasonable Content Security Policy. However, the time is worth spending as it’s an additional layer of security that supports the idea of defense in depth.

Further Reading

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Inspecting Security and Privacy Settings of a Website

Inspecting the Content Security Policy of a Website

Starting in Firefox 41, Mozilla provides a developer tool that allows users to inspect the security settings of a website. Using GCLI (Graphic Command Line Interface) a user can inspect the Content Security Policy (CSP) of a website. CSP is a security concept that allows websites to protect themselves against cross-site scripting (XSS) and related attacks. CSP allows website authors to whitelist approved sources from which content can be loaded safely. Browsers enforce that Content Security Policy header and only allow whitelisted resources to be loaded into that website. The CSP inspection tool » security csp lists all whitelisted sources.

The main intention behind CSP is to protect websites against XSS attacks, but the protection needs to be deployed in a way that allows support for legacy code on these sites. For example, the keyword ‘unsafe-inline’ was originally introduced to support legacy inline scripts while transitioning sites to use CSP. This keyword whitelists all inline scripts for a site, but it also allows attacker-injected scripts to execute, making CSP ineffective against most XSS attacks. Hence, the CSP devtool not only lists all whitelisted sources, but also provides a rating for each whitelisted source, to indicate the level of protection.

Inspecting the referrer policy of a website


Starting in Firefox 43, Mozilla exposes more website privacy settings and also allows users to inspect the Referrer Policy » security referrer. The referrer policy allows websites to exercise more control over the browser’s referrer header. Specifically it allows website authors to instruct the browser to strip the referrer completely, reveal it only when navigating within the same origin, etc. The referrer devtool provides an example of what referrer will be used when visiting different websites, allowing the user and developer to inspect what information is sent when following a link.

Inspecting the Content Security Policy as well as the Referrer Policy is only the starting point to providing end users with more feedback about the security and privacy settings a web page uses. We hope to add more tools in the future to give users more transparency and control over the security and privacy of the websites they visit.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Firefox OS Security: Part 2 – User Experience and Security Updates

When presenting Firefox OS to people, security is a big topic. Can an operating system built on web technologies be secure? What has Mozilla built in to avoid drive-by downloads and malware? How can a browser-based app be secure without making the UX suffer by asking the user to react to a lot of “do you want to allow this?”. In this, the second of a two part video series Christian Heilmann (@codepo8), principal evangelist of Mozilla, talks to Michael Coates (@_mwc), chair of @OWASP Board about the user experience when it comes to installing and using apps and the security update model for Firefox OS.

You can watch the video on YouTube.

Firefox OS was built on top of the technologies that power the Web. Following Mozilla’s security practices and knowledge from over 10 years of securing Firefox, Firefox OS is engineered as a multi-tiered system that protects users while delivering the power of the mobile web. The design ensures users are in control of their data and developers have APIs and technologies at their disposal to unlock the power of the Web.

Additional links for more information:

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Firefox OS Security: Part 1 – The Web Security Model

When presenting Firefox OS to people, security is a big topic. Can an operating system built on web technologies be secure? What has Mozilla built in to avoid drive-by downloads and malware? In this two part video series Christian Heilmann (@codepo8), principal evangelist of Mozilla, talks to Michael Coates (@_mwc), chair of @OWASP Board about all things security in Firefox OS.

Firefox OS was built on top of the technologies that power the Web. Following Mozilla’s security practices and knowledge from over 10 years of securing Firefox, Firefox OS is engineered as a multi-tiered system that protects users while delivering the power of the mobile web. The design ensures users are in control of their data and developers have APIs and technologies at their disposal to unlock the power of the Web.

Watch the following video where we talk more about the security design and controls present in Firefox OS. In this, the first of two videos on Firefox OS security, we’ll cover items such as the multi-tiered architecture, the permission model, run time decision making, protection of users data and the update model. You can watch the video on YouTube.

Additional links for more information:

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Content Security Policy 1.0 lands in Firefox Aurora

The information in this article is based on work together with Ian Melven, Kailas Patil and Tanvi Vyas.

We have just landed support for the Content Security Policy (CSP) 1.0
specification
in Firefox Aurora (Firefox 23), available as of tomorrow (May 30th). CSP is a security mechanism that aims to protect a website against content injection attacks by providing a whitelist of known-good domain names to accept JavaScript (and other content) from. CSP does this by sending a Content-Security-Policy header with the document it protects (yes, we lost the X prefix with the 1.0 version of the spec).

To effectively protect against XSS, a few JavaScript features have to be
disabled:

  • All inline JavaScript is disallowed. This means, that all the JavaScript code must be placed in a separate file that is linked via <script src=... >
  • All calls to functions which allow JavaScript code being executed from strings (e.g., eval) are disabled

CSP now more intuitive and consistent

While Firefox has had support for CSP since its invention here at Mozilla, things have been changing a lot. The streamlined development of a specification within the W3C has made the concept more intuitive and consistent. Most directives in a CSP header are now of a unified form which explicitly specifies the type of content you want to restrict:

  • img-src
  • object-src
  • script-src
  • style-src and so on.

Oh and if you feel like you must allow less secure JavaScript coding styles, you can add the values unsafe-inline or unsafe-eval to your list of script sources. (This used to be inline-script and eval-script before).

Start protecting your website by implementing CSP now!

But wait – isn’t that a bit tedious… Writing a complex policy and making sure that you remembered all the resources that your website requires? Don’t fret! Here comes UserCSP again!

Generate your Content Security Policies with UserCSP!

During the last few months, Kailas Patil, a student in our Security Mentorship Program has continued his GSoC work from last
year
to update UserCSP.

UserCSP is a Firefox add-on that helps web developers and security-minded users use CSP. Web developers can create a Content Security Policy (CSP) for their site by using UserCSP’s infer CSP feature. This feature can list required resource URLs and turn them into a policy ready to plug into a CSP header.

In addition, UserCSP is the first step to expose a policy enforcement mechanism directly to web users. Furthermore, users can enforce a stricter policy than a page supplies through the add-on or apply a policy to certain websites that don’t currently support CSP.

While earlier versions of UserCSP were more aligned to content security policies as originally invented at Mozilla, this version is updated to be in compliance with the CSP 1.0 specification. This means that policies derived with this add-on may work in all browsers as soon as they support the specification. Hooray!

As this evolves and ships, our MDN documentation on Content Security Policy (CSP) will keep on evolving, and we also plan to write more about this in the Mozilla Security Blog in the next few weeks, so stay tuned!

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)