Untrusted environment: Difference between revisions
Content deleted Content added
m →{{header|Phix}}: added a code snippet and some comments about p2js |
Added FreeBASIC |
||
(2 intermediate revisions by 2 users not shown) | |||
Line 30:
Beware of allowing user input to fed to the reverse polish calculator. It has the ability to run shell commands, and this could be a security risk:
<
=={{header|FreeBASIC}}==
FreeBASIC does not have built-in functions specifically designed to handle untrusted input or code. However, there are general practices that can be followed to mitigate the risks associated with untrusted input:
# '''Input Validation''': Always validate user input before using it. This can help prevent issues like SQL injection, buffer overflow, etc.
# Prevent execution of untrusted code: FreeBASIC does not have a function to execute code dynamically (such as eval in JavaScript). But this is a good thing from a security point of view, as it reduces the risk of arbitrary code execution.
# Error Handling: Always include error handling in your code. This can prevent unexpected behavior and give you more control over what happens when an error occurs.
# '''Limiting system access''': Be careful when using system-level commands (such as SHELL). These can potentially be exploited to execute arbitrary commands on the host system.
# '''Safe Libraries and Functions''': Use libraries and functions that are known to be safe. Avoid using outdated or insecure features.
=={{header|Go}}==
Line 40 ⟶ 48:
The following example shows how to use a combination of reflection and pointer arithmetic to indirectly (and unsafely) change the contents of a byte slice.
<
import (
Line 58 ⟶ 66:
}
fmt.Println(string(bs))
}</
{{out}}
Line 103 ⟶ 111:
=={{header|Lua}}==
Lua supports protected calls and custom environments. Details have changed through various versions, and the specifics can become quite involved if/as needed, however the following might suffice as a simple example for Lua 5.2 or 5.3.
<
print("hello") -- safe
for i = 1, 7 do print(i, i*i) end -- safe
Line 110 ⟶ 118:
sandbox = { print=print }
local ret, msg = pcall(load(untrusted,nil,nil,sandbox))
print("ret, msg:", ret, msg)</
{{out}}
<pre>hello
Line 150 ⟶ 158:
GP has a default, <code>secure</code>, which disallows the <code>system</code> and <code>extern</code> commands. Once activated this default cannot be removed without input from the user (i.e., not a script).
<
system("del file.txt");
default(secure,0); \\ Ineffective without user input</
=={{header|Perl}}==
Perl can be invoked in taint mode with the command line option <code>-T</code>. While in this mode input from the user, and all variables derived from it, cannot be used in certain contexts until 'sanitized' by being passed through a regular expression.
<
my $f = $ARGV[0];
open FILE, ">$f" or die 'Cannot open file for writing';
print FILE "Modifying an arbitrary file\n";
close FILE;</
=={{header|Phix}}==
'''with safe_mode''' disables most potentially dangerous features such as file i/o, and invoking c_func/proc() or using inline assembly outside of Phix\builtins\, which should make it safer to try out code from an untrusted source. It behaves identically to a -safe command line option, however relying on the latter risks leaving a dangerous file lying around that might accidentally be run without the proper command line flag in some idle moment much later, whereas of course if you put it in the source, that's not such an issue.
<!--<
<span style="color: #000080;font-style:italic;">-- demo\rosetta\safe_mode.exw
--
Line 172 ⟶ 180:
--</span>
<span style="color: #008080;">with</span> <span style="color: #008080;">javascript_semantics</span> <span style="color: #000080;font-style:italic;">-- (erm, it kinda is anyway...)</span>
<span style="color: #008080;">with</span> <span style="color: #
<span style="color: #004080;">sequence</span> <span style="color: #000000;">cl</span> <span style="color: #0000FF;">=</span> <span style="color: #7060A8;">command_line</span><span style="color: #0000FF;">()</span>
Line 181 ⟶ 189:
--#ilASM{ mov eax,1 }
-- The above would be rejected outright by pwa/p2js anyway, with or without safe_mode</span>
<!--</
Note that builtins\VM\pDiagN.e has to switch it off (eg to write an ex.err file when the program crashes), which is trivial to do but only via #ilASM{}, so a malicious programmer simply cannot, that is, as long as you actually use safe_mode, and don't ever put untrusted code into the builtins\ directory. Special allowances are made for mpfr.e (aka gmp) and pGUI.e (aka IUP), since they're not inherently dangerous; there might be some other libraries that deserve similar treatment.
Line 197 ⟶ 205:
=={{header|Racket}}==
The <tt>racket/sandbox</tt> library provides a way to construct limited evaluators which are prohibited from using too much time, memory, read/write/execute files, using the network, etc.
<
#lang racket
(require racket/sandbox)
(define e (make-evaluator 'racket))
(e '(...unsafe code...))
</syntaxhighlight>
The idea is that a default sandbox is suitable for running arbitrary code without any of the usual risks. The library can also be used with many different configurations, to lift some of the restriction, which is more fitting in different cases.
Line 232 ⟶ 240:
For example, given ''cat.rexx'':
<
{{out}}
Line 246 ⟶ 254:
=={{header|Ruby}}==
Ruby handles untrusted input with the global variable <code>$SAFE</code>. Settings higher than 0 invoke an increasing level of sandboxing and general paranoia.
<
$SAFE = 4
cgi = CGI::new("html4")
eval(cgi["arbitrary_input"].to_s)</
=={{header|Rust}}==
Line 273 ⟶ 281:
=={{header|Tcl}}==
Tcl allows evaluation of untrusted code through ''safe interpreters'', which are evaluation contexts where all unsafe operations are removed. This includes access to the filesystem, access to environment variables, the opening of sockets, description of the platform, etc.
<
$context eval $untrustedCode</
Because the only way that Tcl code can perform an operation is by invoking a command if that command is not present in the execution context then the functionality is gone.
It is possible to profile in restricted versions of operations to allow things like access to built-in packages.
<
$context eval $untrustedCode</
These work by installing aliases from the otherwise-removed commands in the safe interpreter to implementations of the commands in the parent master interpreter that take care to restrict what can be accessed. Note that the majority of unsafe operations are still not present, and the paths supported to the packages are virtualized; no hole is opened up for performing unsafe operations unless a package author is deliberately careless in their C implementation.
Line 287 ⟶ 295:
Variable references should be contained in double quotes to prevent an empty string causing an error as a result of omission during evaluation:
<
num=`expr "$num" + 1` # The quotes are an improvement</
=== Do not allow users to run programs that can launch a new shell ===
Line 301 ⟶ 309:
However, the restricted shell is not completely secure. A user can break out of the restricted environment by running a program that features a shell function. The following is an example of the shell function in vi being used to escape from the restricted shell:
<
:set shell=/bin/sh
:shell</
=== Use a chroot jail ===
Sometimes chroot jails are used to add a layer of security to
<
cd ~/jail;
chroot ~/jail;
setuid(9); # if 9 is the userid of a non-root user
rm /etc/hosts # actually points to ~/jail/etc/hosts</
=={{header|Wren}}==
|