<!--
/***************************************************************************************************************************
 * Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements.  See the NOTICE file
 * distributed with this work for additional information regarding copyright ownership.  The ASF licenses this file
 * to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance
 * with the License.  You may obtain a copy of the License at
 *  
 *  http://www.apache.org/licenses/LICENSE-2.0
 *  
 * Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an
 * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  See the License for the
 * specific language governing permissions and limitations under the License.
 ***************************************************************************************************************************/
 -->

juneau-svl

<p>
	Care must be used when defining new {@link oaj.svl.Var Vars} using the SVL API since mistakes 
	could potentially expose system properties, environment variables, or even file system files.
</p>
<p>
	For recap, the SVL support allows you to embed variables of the form <js>"$X{key}"</js> inside strings that
	get resolved to other strings.  The resolved strings themselves can also contain variables that also
	get recursively resolved.  
</p>
<p>
	An example of a potential security hole is shown below that could potentially expose any file on a file
	system through a REST request:
</p>
<p class='bpcode w800'>
	<jk>public</jk> String doUnsafeGet(RestRequest req) {
		<jc>// Security hole!</jc>
		<jk>return</jk> req.getVarResolver().resolve(<js>"$RQ{foo}"</js>);
	}
</p>
<p>
	This code is simply echoing the value of the <c>foo</c> query parameter.
	Now say for example that a bad actor passes in the query string <js>"foo=$F{/some/file/on/file/system}"</js>.
	The <c>$F</c> variable allows you to resolve the contents of files using SVL, and is provided
	by default using the built-in variable resolver returned by the <c>RestRequest</c> object.
	You've potentially just exposed the contents of that file through your REST interface.
</p>
<p>
	In reality, the above security hole does not exist because of the following restrictions:
</p>
<ul class='spaced-list'>
	<li>
		<c>Vars</c> have two methods {@link oaj.svl.Var#allowNested()} and 
		{@link oaj.svl.Var#allowRecurse()} that can be overridden to prevent recursive processing
		of string variables.  These are both <jk>false</jk> for the <c>$R</c> variable, so the <c>$F</c>
		variable in the result will never get processed and instead be treated as plain text. 
	<li>
		The <c>$F</c> variable only allows you to retrieve files within the JVM starting directory. 
</ul>
<p>
	Even though the built-in Juneau variables are safe, special care is needed when defining your own custom
	variables.  If your variable resolves user input in any way, it's HIGHLY recommended that you override the
	{@link oaj.svl.Var#allowNested()} and {@link oaj.svl.Var#allowRecurse()} 
	methods to prevent recursive handling of variables.
</p>