This is an automated email from the ASF dual-hosted git repository.

ddekany pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/freemarker-site.git


The following commit(s) were added to refs/heads/asf-site by this push:
     new f908bd7  Manual: Improved user uploaded template security FAQ entry
f908bd7 is described below

commit f908bd72c57b98e633d84b5e64d9368b92f0cbf8
Author: ddekany <[email protected]>
AuthorDate: Sat Mar 28 11:02:47 2020 +0100

    Manual: Improved user uploaded template security FAQ entry
---
 docs/app_faq.html | 45 +++++++++++++++++++++++++++++----------------
 1 file changed, 29 insertions(+), 16 deletions(-)

diff --git a/docs/app_faq.html b/docs/app_faq.html
index 4f4f8a1..7544270 100644
--- a/docs/app_faq.html
+++ b/docs/app_faq.html
@@ -1626,7 +1626,7 @@ TemplateModel x = env.getVariable(&quot;x&quot;);  // get 
variable x</pre></div>
             application developers, system administrators, or other highly
             trusted personnel. Consider templates as part of the source code
             just like <code class="inline-code">*.java</code> files are. If 
you still want
-            to allow users to upload templates, here&#39;s what to
+            to allow untrusted users to upload templates, here&#39;s what to
             consider:</p>
 
             <ul>
@@ -1635,7 +1635,7 @@ TemplateModel x = env.getVariable(&quot;x&quot;);  // get 
variable x</pre></div>
                 (<code 
class="inline-code">Configuration.setObjectWrapper</code>): The
                 data-model might gives access to the public Java API of some
                 objects that you have put into the data-model. By default, for
-                objects that aren&#39;t instances of a the bunch of specially
+                objects that aren&#39;t instances of the bunch of specially
                 handled types (<code class="inline-code">String</code>,
                 <code class="inline-code">Number</code>, <code 
class="inline-code">Boolean</code>,
                 <code class="inline-code">Date</code>, <code 
class="inline-code">Map</code>,
@@ -1652,7 +1652,7 @@ TemplateModel x = env.getVariable(&quot;x&quot;);  // get 
variable x</pre></div>
                 <code class="inline-code">List</code>-s, <code 
class="inline-code">Array</code>-s,
                 <code class="inline-code">String</code>-s, <code 
class="inline-code">Number</code>-s,
                 <code class="inline-code">Boolean</code>-s and <code 
class="inline-code">Date</code>-s.
-                But for many application that&#39;s too restrictive, and 
instead
+                But for many applications that&#39;s too restrictive, and 
instead
                 you have to create a
                 <code class="inline-code">WhitelistMemberAccessPolicy</code>, 
and create a
                 <code class="inline-code">DefaultObjectWrapper</code> (or other
@@ -1664,10 +1664,24 @@ TemplateModel x = env.getVariable(&quot;x&quot;);  // 
get variable x</pre></div>
                 <code class="inline-code">ObjectWrapper</code> implementation 
of
                 course.)</p>
 
+                <p>Always expect that templates may get some objects that
+                you haven&#39;t put into the data-model yourself. Notably,
+                templates can always get a <code 
class="inline-code">Locale</code> object
+                with the <code class="inline-code">.locale_object</code> 
expression. Or the
+                web application framework you are using may exposes some
+                objects, like attributes from the Servlet scopes. Such objects
+                will be still wrapped with the
+                <code class="inline-code">ObjectWrapper</code> that you set in 
the
+                <code class="inline-code">Configuration</code>, and this is 
why it&#39;s
+                important to ensure safety on that level. Controlling what
+                objects the template will have access is hard, but you can
+                control centrally what members of any object they have access
+                to.</p>
+
                 <p>If you are creating <code 
class="inline-code">TemplateModel</code>-s
                 in custom code (instead of the
-                <code class="inline-code">ObjectWrapper</code> creating 
those), be sure you
-                avoid deprecated container constructors like <code 
class="inline-code">new
+                <code class="inline-code">ObjectWrapper</code> creating 
those), be sure that
+                you avoid deprecated container constructors like <code 
class="inline-code">new
                 SimpleSequence()</code>, as those will use the also
                 deprecated default object wrapper instance, which doesn&#39;t 
have
                 the same restrictions than the
@@ -1691,18 +1705,17 @@ TemplateModel x = env.getVariable(&quot;x&quot;);  // 
get variable x</pre></div>
                 by the <code class="inline-code">MemberAccessPolicy</code> 
also won&#39;t be
                 visible with <code class="inline-code">?api</code> (assuming 
you are using a
                 well behaving <code class="inline-code">ObjectWrapper</code>, 
like
-                <code class="inline-code">DefaultObjectWrapper</code> is, 
hopefully.)</p>
+                <code class="inline-code">DefaultObjectWrapper</code>.)</p>
 
-                <p>Last not least, some maybe aware of that the standard
-                object wrappers filters out some well known
-                "unsafe" methods, like
+                <p>Last not least, some maybe aware of the historical
+                legacy that standard object wrappers filter out some well
+                known "unsafe" methods, like
                 <code class="inline-code">System.exit</code>. Do not ever rely 
on that,
-                since it only blocks the methods that&#39;s in a small 
predefined
-                list (for some historical reasons). The standard Java API is
-                huge and ever growing, and then there are the 3rd party
-                libraries, and the API-s of your own application. Clearly 
it&#39;s
-                impossible to blacklist all the problematic members in
-                those.</p>
+                since it only blocks the methods from a small predefined list.
+                The standard Java API is huge and ever growing, and then there
+                are the 3rd party libraries, and the API-s of your own
+                application. Clearly it&#39;s impossible to blacklist all the
+                problematic members in those.</p>
               </li>
 
               <li>
@@ -1907,7 +1920,7 @@ TemplateModel x = env.getVariable(&quot;x&quot;);  // get 
variable x</pre></div>
     </div>
 <div class="site-footer"><div class="site-width"><div class="footer-top"><div 
class="col-left sitemap"><div class="column"><h3 
class="column-header">Overview</h3><ul><li><a 
href="https://freemarker.apache.org/";>What is FreeMarker?</a></li><li><a 
href="https://freemarker.apache.org/freemarkerdownload.html";>Download</a></li><li><a
 href="app_versions.html">Version history</a></li><li><a 
href="https://freemarker.apache.org/history.html";>About us</a></li><li><a 
itemprop="license" href="app_li [...]
 Last generated:
-<time itemprop="dateModified" datetime="2020-03-06T23:54:59Z" title="Friday, 
March 6, 2020 11:54:59 PM GMT">2020-03-06 23:54:59 GMT</time>, for Freemarker 
2.3.30 </p>
+<time itemprop="dateModified" datetime="2020-03-28T09:59:00Z" title="Saturday, 
March 28, 2020 9:59:00 AM GMT">2020-03-28 09:59:00 GMT</time>, for Freemarker 
2.3.30 </p>
 <p class="copyright">
 © <span itemprop="copyrightYear">1999</span>–2020
 <a itemtype="http://schema.org/Organization"; itemprop="copyrightHolder" 
href="https://apache.org/";>The Apache Software Foundation</a>. Apache 
FreeMarker, FreeMarker, Apache Incubator, Apache, the Apache FreeMarker logo 
are trademarks of The Apache Software Foundation. All other marks mentioned may 
be trademarks or registered trademarks of their respective owners. </p>

Reply via email to