This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "OWASP Embedded Application Security"

From OWASP
Jump to: navigation, search
(Embedded Secure Coding Best Practices)
Line 1: Line 1:
{{Template:Project About
+
= Main =
| project_name =OWASP Embedded Application Security
+
<div style="width:100%;height:100px;border:0,margin:0;overflow: hidden;">[[File:Incubator_big.jpg|link=OWASP_Project_Stages#tab=Incubator_Projects]]</div>
| project_description = Each year, the number of enterprise and consumer devices with embedded software are on the rise. Given the publicity with IoT and more devices becoming network connected, it is essential to create secure coding guidelines for embedded software. Embedded Application Security is not often a high priority for embedded devices such as Routers, Managed Switches, IoT devices, and even ATM Kiosks. There are many challenges in the embedded field including ODM supply chain, limited memory, a small stack, and the challenge of pushing firmware updates securely to an endpoint.
+
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
 +
| valign="top"  style="border-right: 1px dotted gray;padding-right:25px;" |
 +
 
 +
==OWASP Embedded Application Security Project ==
 +
 
 +
Each year, the number of enterprise and consumer devices with embedded software are on the rise. Given the publicity with IoT and more devices becoming network connected, it is essential to create secure coding guidelines for embedded software. Embedded Application Security is not often a high priority for embedded devices such as Routers, Managed Switches, IoT devices, and even ATM Kiosks. There are many challenges in the embedded field including ODM supply chain, limited memory, a small stack, and the challenge of pushing firmware updates securely to an endpoint.
 
The goal of this project is to identify the risks in embedded applications on a generalized list of devices, create a list of best practices, draw on the resources that OWASP already has, and bring OWASP expertise to the embedded world.
 
The goal of this project is to identify the risks in embedded applications on a generalized list of devices, create a list of best practices, draw on the resources that OWASP already has, and bring OWASP expertise to the embedded world.
| project_license =
 
| leader_name1 = Aaron Guzman
 
| leader_email1 = [email protected]
 
| leader_username1 =
 
| leader_name2 =
 
| leader_email2 =
 
| leader_username2 =
 
| contributor_name1 =
 
| contributor_email1 =
 
| contributor_username1 =
 
| contributor_name2 =
 
| contributor_email2 =
 
| contributor_username2 =
 
| mailing_list_name = [mailto:[email protected] Mailing List]
 
| links_url1 =
 
| links_name1 =
 
| links_url1 =
 
| links_name1 =
 
}} 
 
  
Google Group - https://groups.google.com/a/owasp.org/forum/?hl=en#!forum/embedded-appsec
+
==Introduction==
 +
 
 +
<i>Contextual Output Encoding</i> is a computer programming technique necessary to stop [https://www.owasp.org/index.php/XSS_Prevention_Cheat_Sheet Cross Site Scripting]. This project is a Java 1.5+ simple-to-use drop-in high-performance encoder class with no dependencies and little baggage. It provides numerous encoding functions to help defend against XSS in a variety of different HTML, JavaScript, XML and CSS contexts.
 +
 
 +
==Quick Overview==
 +
 
 +
The OWASP Java Encoder library is intended for quick contextual encoding with very little overhead, either in performance or usage. To get started, simply add the encoder-1.2.jar, import org.owasp.encoder.Encode and start encoding.
 +
 
 +
Please look at the [http://search.maven.org/remotecontent?filepath=org/owasp/encoder/encoder/1.2/encoder-1.2-javadoc.jar javadoc for Encode] to see the variety of contexts for which you can encode. Tag libraries and JSP EL functions can be found in the encoder-jsp-1.2.jar.
 +
 
 +
If you want to try it out or see it in action, head over to "Can You XSS This? (.com)" and hit it with your best XSS attack vectors!
 +
 
 +
Happy Encoding!
 +
 
 +
==Licensing==
 +
The OWASP Java Encoder is free to use under the [http://opensource.org/licenses/BSD-3-Clause New BSD License].
 +
 
  
=== Embedded Device Secure Coding Best Practices ===
+
| valign="top"  style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |
  
# Prevent the use of dangerous functions and APIs in efforts to protect against memory-corruption vulnerabilities inside firmware functions.
+
== What is this? ==
# Ensure secure compiler flags or switches are utilized upon each firmware build. (i.e For GCC -fPIE, -fstack-protector-all, -Wl,-z,noexecstack, -Wl,-z,noexecheap etc..)
+
 
# Ensure robust update mechanisms utilize cryptographically signed firmware images for updating functions.
+
The OWASP Java Encoder provides:
# Do not hard code secrets such as passwords, usernames, tokens or similar variants into firmware images.
+
 
# Dispose and securely wipe sensitive information stored in buffers or temporary files during runtime after they are no longer needed (e.g. Wipe buffers from locations where personal identifiable information is stored before releasing the buffers)
+
* Output Encoding functions to help stop XSS
# Modify Busybox and embedded frameworks alike to only libraries and functions that are being used. (e.g. Remove unused languages like perl and services such as Telnet, FTP etc)
+
* Java 1.5+ standalone library
# Validate all debugging and pre-production code have been removed prior to firmware deployment.  
+
 
# Ensure all methods of communication are utilizing industry standard encryption configurations for TLS.
+
== Important Links ==
# Limit collection, storage, and sharing of personal identifiable information (PII) to items that are only required for operation.
+
 
# Ensure kernel and software packages on embedded images are updated to prevent from known publicly available exploits.
+
[https://github.com/OWASP/owasp-java-encoder/ Java Encoder at GitHub]<br/>
 +
[https://github.com/owasp/owasp-java-encoder/issues Issue Tracker]
 +
 
 +
== Mailing List ==
 +
 
 +
[https://lists.owasp.org/mailman/listinfo/owasp-java-encoder-project Java Encoder Mailing List]
 +
 
 +
== Project Leaders ==
 +
Author:  Jeff Ichnowski [mailto:jeff.[email protected].com @]<br/>
 +
[https://www.owasp.org/index.php/User:Jmanico Jim Manico] [mailto:jim.[email protected].org @]<br/>
 +
[https://www.owasp.org/index.php/User:Jeremy_Long Jeremy Long] [mailto:jeremy.[email protected].org @]
  
 
== Related Projects ==
 
== Related Projects ==
  
* [[OWASP_Internet_of_Things_Project|OWASP Internet of Things Project]]
+
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet]]
* [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]
+
* [[OWASP Java HTML Sanitizer Project]]
* [[C-Based_Toolchain_Hardening|OWASP C-Based Toolchain Hardening]]
+
* [[OWASP JSON Sanitizer]]
 +
* [[OWASP Dependency Check]]
 +
* [https://github.com/sourceclear/headlines Sourceclear Headlines]
 +
* [https://code.google.com/p/keyczar/ Google KeyCzar]
 +
* [http://shiro.apache.org/ Apache SHIRO]
 +
 
 +
 
 +
| valign="top"  style="padding-left:25px;width:200px;" |
 +
 
 +
== Quick Download ==
 +
 
 +
* [https://search.maven.org/remotecontent?filepath=org/owasp/encoder/encoder/1.2/encoder-1.2.jar encoder-1.2.jar]
 +
* [https://search.maven.org/remotecontent?filepath=org/owasp/encoder/encoder-jsp/1.2/encoder-jsp-1.2.jar encoder-jsp-1.2.jar]
 +
 
 +
== News and Events ==
 +
* [11 June 2016] No reported issues and library use is strong!
 +
* [1 May 2015] Moved to GitHub
 +
* [12 Apr 2015] 1.2 Released!
 +
* [10 Apr 2015] GitHub move
 +
* [1 Feb 2015] Removed ThreadLocal
 +
* [20 Mar 2014] Doc additions
 +
* [5 Feb 2014] New Wiki
 +
* [4 Feb 2014] 1.1.1 Released
 +
 
 +
== In Print ==
 +
We will be releasing a user guide soon!
 +
 
 +
==Classifications==
 +
 
 +
  {| width="200" cellpadding="2"
 +
  |-
 +
  | align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
 +
  | align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]] 
 +
  |-
 +
  | align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
 +
  |-
 +
  | colspan="2" align="center"  | [http://opensource.org/licenses/BSD-3-Clause New BSD License]
 +
  |-
 +
  | colspan="2" align="center"  | [[File:Project_Type_Files_CODE.jpg|link=]]
 +
  |}
 +
 
 +
|}
 +
 
 +
= Use the Java Encoder Project =
 +
 
 +
The general API pattern is to utilize the Java Encoder Project in your user interface code and wrap all variables added dynamically to HTML with a proper encoding function. The encoding pattern is <b>"Encode.forContextName(untrustedData)"</b>, where "ContextName" is the name of the target context and "untrustedData" is untrusted output.
 +
 
 +
== Basic HTML Context ==
 +
 
 +
<body><%= <b>Encode.forHtml(UNTRUSTED)</b> %></body>
 +
 
 +
== HTML Content Context ==
 +
<textarea name="text"><%= <b>Encode.forHtmlContent(UNTRUSTED)</b> %></textarea>
 +
 
 +
== HTML Attribute context ==
 +
 
 +
<input type="text" name="address" value="<%= <b>Encode.forHtmlAttribute(UNTRUSTED)</b> %>" />
 +
 
 +
Generally <b>Encode.forHtml(UNTRUSTED)</b> is also safe but slightly less efficient for the above two contexts (for textarea content and input value text) since it encodes more characters than necessary but might be easier for developers to use.
 +
 
 +
== CSS contexts ==
 +
 
 +
<div style="width:<= <b>Encode.forCssString(UNTRUSTED)</b> %>">
 +
<div style="background:<= <b>Encode.forCssUrl(UNTRUSTED)</b> %>">
 +
 
 +
== Javascript Block context ==
 +
 
 +
  <script type="text/javascript">
 +
  var msg = "<%= <b>Encode.forJavaScriptBlock(UNTRUSTED)</b> %>";
 +
  alert(msg);
 +
  </script>
 +
 
 +
== Javascript Variable context ==
 +
 
 +
  <button
 +
  onclick="alert('<%= <b>Encode.forJavaScriptAttribute(UNTRUSTED)</b> %>');">
 +
  click me</button>
 +
 
 +
JavaScript Content Notes: <b>Encode.forJavaScript(UNTRUSTED)</b> is safe for the above two contexts, but encodes more characters and is less efficient.
 +
 
 +
== Encode URL parameter values ==
 +
<a href="/search?value=<%= <b>Encode.forUriComponent(UNTRUSTED)</b> %>&order=1#top">
 +
 
 +
== Encode REST URL parameters ==
 +
<a href="/page/<%= <b>Encode.forUriComponent(UNTRUSTED)</b> %>">
 +
 
 +
== Handling an Full Untrusted URL ==
 +
 
 +
When handling a full url with the OWASP Java encoder, first verify the URL is a legal URL.
 +
 
 +
String url = validateURL(untrustedInput);
 +
 
 +
Then encode the URL as an HTML attribute when outputting to the page. Note the linkable text needs to be encoded in a different context.
 +
 
 +
  <a href="<%= <b>Encode.forHtmlAttribute(untrustedUrl)</b> %>">
 +
  <%= <b>Encode.forHtmlContent(untrustedLinkName)</b> %>
 +
  </a>
 +
 
 +
== To use in a JSP with EL ==
 +
 
 +
<%@page contentType="text/html" pageEncoding="UTF-8"%>
 +
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
 +
    "<nowiki>http://www.w3.org/TR/html4/loose.dtd</nowiki>">
 +
<%@taglib prefix="e" uri="<nowiki>https://www.owasp.org/index.php/OWASP_Java_Encoder_Project</nowiki>" %>
 +
<html>
 +
    <head>
 +
        <title><b><e:forHtml value="${param.title}" /></b></title>
 +
    </head>
 +
    <body>
 +
        &lt;h1&gt;<b>${e:forHtml(param.data)}</b>&lt;/h1&gt;
 +
    </body>
 +
</html>
 +
 
 +
Other contexts can be found in the org.owasp.Encode class methods, including CSS strings, CSS urls, XML contexts, URIs and URI components.
 +
 
 +
= Deploy the Java Encoder Project =
 +
 
 +
Prevent the use of dangerous functions and APIs in efforts to protect against memory-corruption vulnerabilities inside firmware functions.
 +
Ensure secure compiler flags or switches are utilized upon each firmware build. (i.e For GCC -fPIE, -fstack-protector-all, -Wl,-z,noexecstack, -Wl,-z,noexecheap etc..)
 +
Ensure robust update mechanisms utilize cryptographically signed firmware images for updating functions.
 +
Do not hard code secrets such as passwords, usernames, tokens or similar variants into firmware images.
 +
Dispose and securely wipe sensitive information stored in buffers or temporary files during runtime after they are no longer needed (e.g. Wipe buffers from locations where personal identifiable information is stored before releasing the buffers)
 +
Modify Busybox and embedded frameworks alike to only libraries and functions that are being used. (e.g. Remove unused languages like perl and services such as Telnet, FTP etc)
 +
Validate all debugging and pre-production code have been removed prior to firmware deployment.
 +
Ensure all methods of communication are utilizing industry standard encryption configurations for TLS.
 +
Limit collection, storage, and sharing of personal identifiable information (PII) to items that are only required for operation.
 +
Ensure kernel and software packages on embedded images are updated to prevent from known publicly available exploits.
 +
 
 +
= Roadmap =
  
 +
== 2016-2017 Roadmap ==
 +
* Add decoders and canonicalization
 +
* Build more complex examples
  
 
__NOTOC__ <headertabs />
 
__NOTOC__ <headertabs />
  
[[Category:OWASP_Project]] [[Category:OWASP_Document]] [[Category:OWASP_Download]] [[Category:OWASP_Release_Quality_Document]]
+
[[Category:OWASP_Tool]]  
 +
[[Category:OWASP_Alpha_Quality_Tool]]  
 +
[[Category:OWASP_Project|OWASP Java Encoder Project]]

Revision as of 22:20, 18 July 2016

Incubator big.jpg

OWASP Embedded Application Security Project

Each year, the number of enterprise and consumer devices with embedded software are on the rise. Given the publicity with IoT and more devices becoming network connected, it is essential to create secure coding guidelines for embedded software. Embedded Application Security is not often a high priority for embedded devices such as Routers, Managed Switches, IoT devices, and even ATM Kiosks. There are many challenges in the embedded field including ODM supply chain, limited memory, a small stack, and the challenge of pushing firmware updates securely to an endpoint. The goal of this project is to identify the risks in embedded applications on a generalized list of devices, create a list of best practices, draw on the resources that OWASP already has, and bring OWASP expertise to the embedded world.

Introduction

Contextual Output Encoding is a computer programming technique necessary to stop Cross Site Scripting. This project is a Java 1.5+ simple-to-use drop-in high-performance encoder class with no dependencies and little baggage. It provides numerous encoding functions to help defend against XSS in a variety of different HTML, JavaScript, XML and CSS contexts.

Quick Overview

The OWASP Java Encoder library is intended for quick contextual encoding with very little overhead, either in performance or usage. To get started, simply add the encoder-1.2.jar, import org.owasp.encoder.Encode and start encoding.

Please look at the javadoc for Encode to see the variety of contexts for which you can encode. Tag libraries and JSP EL functions can be found in the encoder-jsp-1.2.jar.

If you want to try it out or see it in action, head over to "Can You XSS This? (.com)" and hit it with your best XSS attack vectors!

Happy Encoding!

Licensing

The OWASP Java Encoder is free to use under the New BSD License.


What is this?

The OWASP Java Encoder provides:

  • Output Encoding functions to help stop XSS
  • Java 1.5+ standalone library

Important Links

Java Encoder at GitHub
Issue Tracker

Mailing List

Java Encoder Mailing List

Project Leaders

Author: Jeff Ichnowski @
Jim Manico @
Jeremy Long @

Related Projects


Quick Download

News and Events

  • [11 June 2016] No reported issues and library use is strong!
  • [1 May 2015] Moved to GitHub
  • [12 Apr 2015] 1.2 Released!
  • [10 Apr 2015] GitHub move
  • [1 Feb 2015] Removed ThreadLocal
  • [20 Mar 2014] Doc additions
  • [5 Feb 2014] New Wiki
  • [4 Feb 2014] 1.1.1 Released

In Print

We will be releasing a user guide soon!

Classifications

Owasp-incubator-trans-85.png Owasp-builders-small.png
Owasp-defenders-small.png
New BSD License
Project Type Files CODE.jpg

The general API pattern is to utilize the Java Encoder Project in your user interface code and wrap all variables added dynamically to HTML with a proper encoding function. The encoding pattern is "Encode.forContextName(untrustedData)", where "ContextName" is the name of the target context and "untrustedData" is untrusted output.

Basic HTML Context

<body><%= Encode.forHtml(UNTRUSTED) %></body>

HTML Content Context

<textarea name="text"><%= Encode.forHtmlContent(UNTRUSTED) %></textarea>

HTML Attribute context

<input type="text" name="address" value="<%= Encode.forHtmlAttribute(UNTRUSTED) %>" />

Generally Encode.forHtml(UNTRUSTED) is also safe but slightly less efficient for the above two contexts (for textarea content and input value text) since it encodes more characters than necessary but might be easier for developers to use.

CSS contexts

<div style="width:<= Encode.forCssString(UNTRUSTED) %>">
<div style="background:<= Encode.forCssUrl(UNTRUSTED) %>">

Javascript Block context

 <script type="text/javascript">
 var msg = "<%= Encode.forJavaScriptBlock(UNTRUSTED) %>";
 alert(msg);
 </script>

Javascript Variable context

 <button 
 onclick="alert('<%= Encode.forJavaScriptAttribute(UNTRUSTED) %>');">
 click me</button>

JavaScript Content Notes: Encode.forJavaScript(UNTRUSTED) is safe for the above two contexts, but encodes more characters and is less efficient.

Encode URL parameter values

<a href="/search?value=<%= Encode.forUriComponent(UNTRUSTED) %>&order=1#top">

Encode REST URL parameters

<a href="/page/<%= Encode.forUriComponent(UNTRUSTED) %>">

Handling an Full Untrusted URL

When handling a full url with the OWASP Java encoder, first verify the URL is a legal URL.

String url = validateURL(untrustedInput);

Then encode the URL as an HTML attribute when outputting to the page. Note the linkable text needs to be encoded in a different context.

 <a href="<%= Encode.forHtmlAttribute(untrustedUrl) %>">
 <%= Encode.forHtmlContent(untrustedLinkName) %>
 </a>

To use in a JSP with EL

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   "http://www.w3.org/TR/html4/loose.dtd">
<%@taglib prefix="e" uri="https://www.owasp.org/index.php/OWASP_Java_Encoder_Project" %>
<html>
   <head>
       <title><e:forHtml value="${param.title}" /></title>
   </head>
   <body>
       <h1>${e:forHtml(param.data)}</h1>
   </body>
</html>

Other contexts can be found in the org.owasp.Encode class methods, including CSS strings, CSS urls, XML contexts, URIs and URI components.

Prevent the use of dangerous functions and APIs in efforts to protect against memory-corruption vulnerabilities inside firmware functions. Ensure secure compiler flags or switches are utilized upon each firmware build. (i.e For GCC -fPIE, -fstack-protector-all, -Wl,-z,noexecstack, -Wl,-z,noexecheap etc..) Ensure robust update mechanisms utilize cryptographically signed firmware images for updating functions. Do not hard code secrets such as passwords, usernames, tokens or similar variants into firmware images. Dispose and securely wipe sensitive information stored in buffers or temporary files during runtime after they are no longer needed (e.g. Wipe buffers from locations where personal identifiable information is stored before releasing the buffers) Modify Busybox and embedded frameworks alike to only libraries and functions that are being used. (e.g. Remove unused languages like perl and services such as Telnet, FTP etc) Validate all debugging and pre-production code have been removed prior to firmware deployment. Ensure all methods of communication are utilizing industry standard encryption configurations for TLS. Limit collection, storage, and sharing of personal identifiable information (PII) to items that are only required for operation. Ensure kernel and software packages on embedded images are updated to prevent from known publicly available exploits.

2016-2017 Roadmap

  • Add decoders and canonicalization
  • Build more complex examples