mozilla

Compare Revisions

Security guidelines

Change Revisions

Revision 481349:

Revision 481349 by omerta on

Revision 486507:

Revision 486507 by ptheriault on

Title:
Security guidelines
Security guidelines
Slug:
Web/Apps/Security_guidelines
Web/Apps/Security_guidelines
Tags:
"Security", "Apps"
"Security", "Apps"
Content:

Revision 481349
Revision 486507
t1008    <h3 id="FirefoxOS_Gecko">t
1009      FirefoxOS Gecko
1010    </h3>
1011    <p>
1012      {{draft}}
1013    </p>
1014    <p>
1015      Currently, FirefoxOS Gecko is a superset of Gecko (Firefox)
> - there are APIs that FirefoxOS has acccess to that Firefox does 
> not. 
1016    </p>
1017    <table align="center" class="standard-table">
1018      <caption>
1019        General Firefox(Gecko) Terminology
1020      </caption>
1021      <tbody>
1022        <tr>
1023          <td>
1024            <p>
1025              Content - Something (most commonly script) loaded f
>rom an untrusted source (e.g., a web page). In security discussio 
>ns 'content' can refer to the set of restricted privileges made a 
>vailable to scripts in web content. 
1026            </p>
1027          </td>
1028        </tr>
1029        <tr>
1030          <td>
1031            <p>
1032              <a href="/en-US/docs/Chrome">Chrome</a> - Something
> pertaining to the browser (as oppsed to web content). In securit 
>y discussions, this most commonly refers to a set of privileges w 
>hich allows code to do everything (unlike web content, which is r 
>estricted). <span id="docs-internal-guid-51dcca4b-a464-da9e-10e8- 
>10e78465ee47" style="font-size:15px;font-family:Arial;color:#0000 
>00;background-color:transparent;font-weight:normal;font-style:nor 
>mal;font-variant:normal;text-decoration:none;vertical-align:basel 
>ine;">Has</span> <span style="font-size:15px;font-family:Arial;co 
>lor:#000000;background-color:transparent;font-weight:bold;font-st 
>yle:normal;font-variant:normal;text-decoration:none;vertical-alig 
>n:baseline;">system principal</span> <span style="font-size:15px; 
>font-family:Arial;color:#000000;background-color:transparent;font 
>-weight:normal;font-style:normal;font-variant:normal;text-decorat 
>ion:none;vertical-align:baseline;">which passes all security chec 
>ks (can do anything, can operate as any principal).</span> 
1033            </p>
1034          </td>
1035        </tr>
1036        <tr>
1037          <td>
1038            <p>
1039              <a href="/en-US/docs/XPConnect_wrappers#Security_wr
>appers_exposed_to_chrome">Wrappers</a> - Firefox relies on wrappe 
>rs to provide 'safe' representations of objects from one context  
>in another (e.g., chrome from content and vice versa). In simple  
>terms, wrappers can be thought of as filtering proxies which enfo 
>rce the rules on how content and script from different principals 
> may interact. 
1040            </p>
1041            <ul>
1042              <li>XOW -&gt; XPCCrossOriginWrapper - automatically
> created when an object from one domain is exposed to content fro 
>m another domain 
1043              </li>
1044              <li>SOW -&gt; XPCSystemOnlyWrapper - automatically 
>created when native anonymous content is exposed to JS 
1045              </li>
1046              <li>COW -&gt; XPCChromeObjectWrapper - automaticall
>y created when a chrome object is exposed to content 
1047              </li>
1048              <li>SJOW -&gt; <a href="/en-US/docs/XPConnect_wrapp
>ers">XPCSafeJSObjectWrapper</a> -&gt; Ability to safely access no 
>n-natively-implemented content defined objects 
1049              </li>
1050              <li>XrayWrapper -&gt; <a href="/en-US/docs/XPConnec
>t_wrappers">XPCNativeWrapper</a> - A way to <a href="https://deve 
>loper.mozilla.org/en/XPConnect_wrappers" title="en/XPConnect_wrap 
>pers">wrap up</a> an object so that it's <a href="https://develop 
>er.mozilla.org/en/Safely_accessing_content_DOM_from_chrome" title 
>="en/Safely_accessing_content_DOM_from_chrome">safe to access fro 
>m privileged code</a>. 
1051              </li>
1052            </ul>
1053          </td>
1054        </tr>
1055        <tr>
1056          <td>
1057            <p>
1058              <a href="/en-US/docs/Security_check_basics#Principa
>ls">Principals</a> - A principal represents a security context. T 
>here are 3 types of principals: 
1059            </p>
1060            <ul>
1061              <li>System - Passes all security checks. It subsume
>s itself and all other principals, which means it can operate on  
>any principal, regardless of its security settings. 
1062              </li>
1063              <li>null - fails almost all security checks. It has
> no privileges and can't be accessed by anything but itself and c 
>hrome. They aren't same-origin with anything but themselves. 
1064              </li>
1065              <li>other/web - a triplet of &lt;origin, appId, inb
>rowserframe&gt; 
1066              </li>
1067            </ul>
1068          </td>
1069        </tr>
1070        <tr>
1071          <td>
1072            <a href="/en-US/docs/SpiderMonkey/SpiderMonkey_compar
>tments">Compartments</a> - Compartments are used to create multip 
>le JavaScript memory heaps, which avoids having one heap for all  
>JavaScript objects. Each compartment is a separate JavaScript hea 
>p. 
1073          </td>
1074        </tr>
1075      </tbody>
1076    </table>
1077    <h4 id="Secure_Coding_in_C.2FC.2B.2B">
1078      Secure Coding in C/C++
1079    </h4>
1080    <p>
1081      In addition to web security principles, understanding secur
>e coding practices and common C/C++ vulnerabilities is essential  
>to a successful Gecko security review. Things like buffer overflo 
>ws, format string vulnerabilities, integer overflow, use after fr 
>ee, double free, etc. 
1082    </p>
1083    <p>
1084      <a href="https://www.securecoding.cert.org/confluence/displ
>ay/seccode/">CERT</a> has a <a href="https://www.securecoding.cer 
>t.org/confluence/display/seccode/CERT+C+Secure+Coding+Standard">C 
></a> and <a href="https://www.securecoding.cert.org/confluence/di 
>splay/cplusplus/00.+Introduction">C++</a> guideline that might be 
> useful. There are, obviously, a myriad of other resources to lea 
>rn about C/C++ security. 
1085    </p>
1086    <h4 id="Content.2FChrome_Segregation">
1087      Content/Chrome Segregation
1088    </h4>
1089    <p>
1090      Content/Chrome segregation vulnerabilities are very dangero
>us as Chrome has 'system principal' and is not subjected to secur 
>ity checks (same origin policy). This is an example of a chrome/c 
>ontent segregation vulnerability that lead to 
1091    </p>
1092    <p>
1093      https://bugzilla.mozilla.org/show_bug.cgi?id=801305
1094    </p>
1095    <table class="standard-table">
1096      <caption>
1097        Specific Vulnerabilities
1098      </caption>
1099      <tbody>
1100        <tr>
1101          <td>
1102            <p>
1103              One important difference between writing web conten
>t and chrome code is that in the latter, iframes have chrome priv 
>ileges by default. If this is not desirable (and it probably isn' 
>t) you'll want to explicitly specify it's for content -- e.g., if 
>rame.setAttribute("type", "content"). 
1104            </p>
1105          </td>
1106        </tr>
1107        <tr>
1108          <td>
1109            <p>
1110              Javascript in Chrome code, unless explicitly needs 
>Chrome privileges, should be run in <a href="/en-US/docs/Componen 
>ts.utils.Sandbox">Sandboxes</a> 
1111            </p>
1112          </td>
1113        </tr>
1114        <tr>
1115          <td>
1116            Take care when using wrappedJSObject on content objec
>ts from chrome code (for more information on safely accessing con 
>tent DOM from chrome, refer to <a href="https://developer.mozilla 
>.org/en-US/docs/Safely_accessing_content_DOM_from_chrome">this do 
>cument</a>) 
1117          </td>
1118        </tr>
1119        <tr>
1120          <td>
1121            Remember that functions defined in chrome context exe
>cute with chrome privileges 
1122          </td>
1123        </tr>
1124        <tr>
1125          <td>
1126            In Chrome code, avoid using dangerous JS functions li
>ke eval, setTimeout(string, time), etc. and other related functio 
>ns if at all possible. 
1127          </td>
1128        </tr>
1129        <tr>
1130          <td>
1131            Content being able to access data/functionality it sh
>ouldn't because of a lack of security checks in chrome. Usually,  
>wrappers are used to mitigate this threat. 
1132          </td>
1133        </tr>
1134        <tr>
1135          <td>
1136            <p>
1137              Content passing malicious object to Chrome in order
> to get Chrome to access data or functionality for it. Content ca 
>n pass malicious objects to Chrome in a few different ways: 
1138            </p>
1139            <ul>
1140              <li>Content can pass the object as an argument to a
>ny chrome-implemented object it can reference, since functions ar 
>e callable even without __exposedProps__ 
1141              </li>
1142              <li>Content can set the object as a property that h
>as been exposed as 'w' with __exposedProps__ 
1143              </li>
1144              <li>Content can stick them into a chrome array or t
>ypedarray, since arrays are accessible even without __exposedProp 
>s__ 
1145              </li>
1146            </ul>
1147          </td>
1148        </tr>
1149      </tbody>
1150    </table>
1151    <h4 id="Process_Segregation">
1152      Process Segregation
1153    </h4>
1154    <p>
1155      cpmm and ppmm, child process and parent process communicati
>on. not using cpmm, ppmm to talk between paretn and child 
1156    </p>
1157    <p>
1158      ipc messages to talk with each other, and they include requ
>est id 
1159    </p>
1160    <h4 id="Other_Data_Validation_.26_Sanitization">
1161      Other Data Validation &amp; Sanitization
1162    </h4>
1163    <h4 id="Validate_Permission_Model">
1164      Validate Permission Model
1165    </h4>
1166    <p>
1167      (1 __exposedProps__, make sure we aren't exposing stuff we 
>shouldn't. 2 maybe a content object doesn't have direct access to 
> something, but maybe a method opened to the content object can m 
>anipulate something it shouldn't) &lt;--- this might be more appr 
>opriate in the chrome vs content section. 
1168    </p>
1169    <p>
1170      When talking about the browser, there are more or less 3 ty
>pes: chrome, content and null. When talking about the web, SOP (m 
>ore or less), the idea of an origin is a principal. Then, a permi 
>ssion is either allow, deny or unknown and is determined based of 
> the type of principals interacting 
1171    </p>
1172    <p>
1173      I would imagine permission checking happens automatically a
>t runtime... need to look more into this. 
1174    </p>
1175    <h4 id="Denial_of_Service">
1176      Denial of Service
1177    </h4>
1178    <h4 id="Code_Execution">
1179      Code Execution
1180    </h4>
1181    <p>
1182      https://bugzilla.mozilla.org/show_bug.cgi?id=479560#c0
1183    </p>
1184    <h4 id="Links">
1185      Links
1186    </h4>
1187    <p>
1188      [1] <a href="/en-US/docs/Safely_accessing_content_DOM_from_
>chrome">Safely accessing content DOM from chrome</a> 
1189    </p>
1190    <p>
1191      [2] <a href="/en-US/docs/Security/Firefox_Security_Basics_F
>or_Developers">Firefox Security Basics for Developers [en-US]</a> 
1192    </p>
1193    <p>
1194      [3] <a href="https://developer.mozilla.org/en-US/docs/Secur
>ity_check_basics">Gecko security check basics</a> 
1195    </p>
1196    <p>
1197      [4] <a href="/en/docs/Security_check_basics">Security check
> basics</a> 
1198    </p>
1199    <p>
1200      [5] <a href="https://blog.mozilla.org/gabor/2012/04/18/secu
>rity-wrappers-part-1/">Security wrappers, part 1: Basics</a> 
1201    </p>

Back to History