Kingdom: Input Validation and Representation
Input validation and representation problems ares caused by metacharacters, alternate encodings and numeric representations. Security problems result from trusting input. The issues include: "Buffer Overflows," "Cross-Site Scripting" attacks, "SQL Injection," and many others.
Unsafe Reflection
Abstract
An attacker may be able to create unexpected control flow paths through the application, potentially bypassing security checks.
Explanation
If an attacker can supply values that the application then uses to determine which class to instantiate or which method to invoke, the potential exists for the attacker to create control flow paths through the application that were not intended by the application developers. This attack vector may allow the attacker to bypass authentication or access control checks or otherwise cause the application to behave in an unexpected manner. Even the ability to control the arguments passed to a given method or constructor may give a wily attacker the edge necessary to mount a successful attack.
Example: A common reason that programmers use reflection technology is to implement their own command dispatcher. The following example shows a command dispatcher that does not use reflection:
A programmer might refactor this code to use reflection as follows:
The refactoring initially appears to offer a number of advantages. There are fewer lines of code, the
However, the refactoring allows an attacker to instantiate any object that implements the
One way to address this access control problem is to make the
Although this is an improvement, it encourages a decentralized approach to access control, which makes it easier for programmers to make access control mistakes.
Example: A common reason that programmers use reflection technology is to implement their own command dispatcher. The following example shows a command dispatcher that does not use reflection:
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var ctl:String = String(params["ctl"]);
var ao:Worker;
if (ctl == "Add) {
ao = new AddCommand();
} else if (ctl == "Modify") {
ao = new ModifyCommand();
} else {
throw new UnknownActionError();
}
ao.doAction(params);
A programmer might refactor this code to use reflection as follows:
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var ctl:String = String(params["ctl"]);
var ao:Worker;
var cmdClass:Class = getDefinitionByName(ctl + "Command") as Class;
ao = new cmdClass();
ao.doAction(params);
The refactoring initially appears to offer a number of advantages. There are fewer lines of code, the
if/else blocks have been entirely eliminated, and it is now possible to add new command types without modifying the command dispatcher.However, the refactoring allows an attacker to instantiate any object that implements the
Worker interface. If the command dispatcher is still responsible for access control, then whenever programmers create a new class that implements the Worker interface, they must remember to modify the dispatcher's access control code. If they fail to modify the access control code, then some Worker classes will not have any access control.One way to address this access control problem is to make the
Worker object responsible for performing the access control check. An example of the re-refactored code is as follows:
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var ctl:String = String(params["ctl"]);
var ao:Worker;
var cmdClass:Class = getDefinitionByName(ctl + "Command") as Class;
ao = new cmdClass();
ao.checkAccessControl(params);
ao.doAction(params);
Although this is an improvement, it encourages a decentralized approach to access control, which makes it easier for programmers to make access control mistakes.
desc.dataflow.actionscript.unsafe_reflection
Abstract
Allowing unvalidated input to determine the callback method of a
Continuation object could enable attackers to create unexpected control flow paths through the application, potentially bypassing security checks.Explanation
If an attacker can supply values that the application then uses to determine which class to instantiate or which method to invoke, the attacker might be able to create unexpected control flow paths through the application. This might enable the attacker to bypass authentication or access control checks or possibly cause the application to behave in an unexpected manner.
Example: The following action method initiates an asynchronous request to an external Web service, and sets the
This implementation allows the
Example: The following action method initiates an asynchronous request to an external Web service, and sets the
continuationMethod property, which determines the name of method to be called when receiving a response.
public Object startRequest() {
Continuation con = new Continuation(40);
Map<String,String> params = ApexPages.currentPage().getParameters();
if (params.containsKey('contMethod')) {
con.continuationMethod = params.get('contMethod');
} else {
con.continuationMethod = 'processResponse';
}
HttpRequest req = new HttpRequest();
req.setMethod('GET');
req.setEndpoint(LONG_RUNNING_SERVICE_URL);
this.requestLabel = con.addHttpRequest(req);
return con;
}
This implementation allows the
continuationMethod property to be set by runtime request parameters, which enables attackers to call any function that matches the name.desc.dataflow.apex.unsafe_reflection
Abstract
An attacker may be able to create unexpected control flow paths through the application, potentially bypassing security checks.
Explanation
If an attacker can supply values that the application then uses to determine which class to instantiate or which method to invoke, the potential exists for the attacker to create control flow paths through the application that were not intended by the application developers. This attack vector may allow the attacker to bypass authentication or access control checks or otherwise cause the application to behave in an unexpected manner. Even the ability to control the arguments passed to a given method or constructor may give a wily attacker the edge necessary to mount a successful attack.
Example: Programmers often use reflection to implement command dispatchers. The following example shows a command dispatcher that does not utilize reflection:
A programmer might refactor this code to use reflection as follows:
The refactoring initially appears to offer a number of advantages. There are fewer lines of code, the
However, the refactoring allows an attacker to invoke any method implemented by the
One way to address this access control problem is to make the
Although this is an improvement, it encourages a decentralized approach to access control, which makes it easier for programmers to make access control mistakes.
Example: Programmers often use reflection to implement command dispatchers. The following example shows a command dispatcher that does not utilize reflection:
...
Dim ctl As String
Dim ao As New Worker()
ctl = Request.Form("ctl")
If (String.Compare(ctl,"Add") = 0) Then
ao.DoAddCommand(Request)
Else If (String.Compare(ctl,"Modify") = 0) Then
ao.DoModifyCommand(Request)
Else
App.EventLog("No Action Found", 4)
End If
...
A programmer might refactor this code to use reflection as follows:
...
Dim ctl As String
Dim ao As New Worker()
ctl = Request.Form("ctl")
CallByName(ao, ctl, vbMethod, Request)
...
The refactoring initially appears to offer a number of advantages. There are fewer lines of code, the
if/else blocks have been entirely eliminated, and it is now possible to add new command types without modifying the command dispatcher.However, the refactoring allows an attacker to invoke any method implemented by the
Worker object. If the command dispatcher is responsible for access control, then whenever programmers create a new method in the Worker class, they must remember to modify the dispatcher's access control logic. If this access control logic becomes stale, then some Worker methods will not have any access control.One way to address this access control problem is to make the
Worker object responsible for performing the access control check. An example of the re-refactored code is as follows:
...
Dim ctl As String
Dim ao As New Worker()
ctl = Request.Form("ctl")
If (ao.checkAccessControl(ctl,Request) = True) Then
CallByName(ao, "Do" & ctl & "Command", vbMethod, Request)
End If
...
Although this is an improvement, it encourages a decentralized approach to access control, which makes it easier for programmers to make access control mistakes.
desc.dataflow.dotnet.unsafe_reflection
Abstract
An attacker may be able to create unexpected control flow paths through the application, potentially bypassing security checks.
Explanation
If an attacker can supply values that the application then uses to determine which class to instantiate or which method to invoke, the potential exists for the attacker to create control flow paths through the application that were not intended by the application developers. This attack vector may allow the attacker to bypass authentication or access control checks or otherwise cause the application to behave in an unexpected manner.
This situation becomes a doomsday scenario if the attacker may upload files into a location that appears on the application's path or library path. Under either of these conditions, the attacker may use reflection to introduce new, presumably malicious, behavior into the application.
Example: A common reason that programmers use the reflection API is to implement their own command dispatcher. The following example shows a JNI command dispatcher that uses reflection to execute a Java method identified by a value read from a CGI request. This implementation allows an attacker to call any function defined in
This situation becomes a doomsday scenario if the attacker may upload files into a location that appears on the application's path or library path. Under either of these conditions, the attacker may use reflection to introduce new, presumably malicious, behavior into the application.
Example: A common reason that programmers use the reflection API is to implement their own command dispatcher. The following example shows a JNI command dispatcher that uses reflection to execute a Java method identified by a value read from a CGI request. This implementation allows an attacker to call any function defined in
clazz.
char* ctl = getenv("ctl");
...
jmethodID mid = GetMethodID(clazz, ctl, sig);
status = CallIntMethod(env, clazz, mid, JAVA_ARGS);
...
desc.dataflow.cpp.unsafe_reflection
Abstract
Interpreting user-controlled instructions at runtime can enable attackers to execute malicious code.
Explanation
If an attacker can supply values that the application then uses to determine which method to invoke or which field value to retrieve, the potential exists for the attacker to create control flow paths through the application that were not intended by the application developers. This attack vector might enable the attacker to bypass authentication or access control checks or otherwise cause the application to behave in an unexpected manner.
Example 1: In this example, the application retrieves the name of a function to be called from a command-line argument.
Example 1: In this example, the application retrieves the name of a function to be called from a command-line argument.
Example 2: Similar to previous example, the application uses the
...
func beforeExampleCallback(scope *Scope){
input := os.Args[1]
if input{
scope.CallMethod(input)
}
}
...
reflect package to retrieve the name of a function to be called from a command-line argument.
...
input := os.Args[1]
var worker WokerType
reflect.ValueOf(&worker).MethodByName(input).Call([]reflect.Value{})
...
desc.dataflow.golang.unsafe_reflection
Abstract
An attacker may be able to create unexpected control flow paths through the application, potentially bypassing security checks.
Explanation
If an attacker can supply values that the application then uses to determine which class to instantiate or which method to invoke, the potential exists for the attacker to create control flow paths through the application that were not intended by the application developers. This attack vector may allow the attacker to bypass authentication or access control checks or otherwise cause the application to behave in an unexpected manner. Even the ability to control the arguments passed to a given method or constructor may give a wily attacker the edge necessary to mount a successful attack.
This situation becomes a doomsday scenario if the attacker may upload files into a location that appears on the application's classpath or add new entries to the application's classpath. Under either of these conditions, the attacker may use reflection to introduce new, presumably malicious, behavior into the application.
Example: A common reason that programmers use the reflection API is to implement their own command dispatcher. The following example shows a command dispatcher that does not use reflection:
A programmer might refactor this code to use reflection as follows:
The refactoring initially appears to offer a number of advantages. There are fewer lines of code, the
However, the refactoring allows an attacker to instantiate any object that implements the
One way to address this access control problem is to make the
Although this is an improvement, it encourages a decentralized approach to access control, which makes it easier for programmers to make access control mistakes.
This code also highlights another security problem with using reflection to build a command dispatcher. An attacker may invoke the default constructor for any kind of object. In fact, the attacker is not even constrained to objects that implement the
Access checks may also be compromised further down the code execution chain, if certain Java APIs that perform tasks using the immediate caller's class loader check, are invoked on untrusted objects returned by reflection calls. These Java APIs bypass the SecurityManager check that ensures all callers in the execution chain have the requisite security permissions. Care should be taken to ensure these APIs are not invoked on the untrusted objects returned by reflection as they can bypass security access checks and leave the system vulnerable to remote attacks. For more information on these Java APIs please refer to Guideline 9 of The Secure Coding Guidelines for the Java Programming Language.
This situation becomes a doomsday scenario if the attacker may upload files into a location that appears on the application's classpath or add new entries to the application's classpath. Under either of these conditions, the attacker may use reflection to introduce new, presumably malicious, behavior into the application.
Example: A common reason that programmers use the reflection API is to implement their own command dispatcher. The following example shows a command dispatcher that does not use reflection:
String ctl = request.getParameter("ctl");
Worker ao = null;
if (ctl.equals("Add")) {
ao = new AddCommand();
} else if (ctl.equals("Modify")) {
ao = new ModifyCommand();
} else {
throw new UnknownActionError();
}
ao.doAction(request);
A programmer might refactor this code to use reflection as follows:
String ctl = request.getParameter("ctl");
Class cmdClass = Class.forName(ctl + "Command");
Worker ao = (Worker) cmdClass.newInstance();
ao.doAction(request);
The refactoring initially appears to offer a number of advantages. There are fewer lines of code, the
if/else blocks have been entirely eliminated, and it is now possible to add new command types without modifying the command dispatcher.However, the refactoring allows an attacker to instantiate any object that implements the
Worker interface. If the command dispatcher is still responsible for access control, then whenever programmers create a new class that implements the Worker interface, they must remember to modify the dispatcher's access control code. If they fail to modify the access control code, then some Worker classes will not have any access control.One way to address this access control problem is to make the
Worker object responsible for performing the access control check. An example of the re-refactored code is as follows:
String ctl = request.getParameter("ctl");
Class cmdClass = Class.forName(ctl + "Command");
Worker ao = (Worker) cmdClass.newInstance();
ao.checkAccessControl(request);
ao.doAction(request);
Although this is an improvement, it encourages a decentralized approach to access control, which makes it easier for programmers to make access control mistakes.
This code also highlights another security problem with using reflection to build a command dispatcher. An attacker may invoke the default constructor for any kind of object. In fact, the attacker is not even constrained to objects that implement the
Worker interface; the default constructor for any object in the system can be invoked. If the object does not implement the Worker interface, a ClassCastException will be thrown before the assignment to ao, but if the constructor performs operations that work in the attacker's favor, the damage will have already been done. Although this scenario is relatively benign in simple applications, in larger applications where complexity grows exponentially it is not unreasonable to assume that an attacker could find a constructor to leverage as part of an attack.Access checks may also be compromised further down the code execution chain, if certain Java APIs that perform tasks using the immediate caller's class loader check, are invoked on untrusted objects returned by reflection calls. These Java APIs bypass the SecurityManager check that ensures all callers in the execution chain have the requisite security permissions. Care should be taken to ensure these APIs are not invoked on the untrusted objects returned by reflection as they can bypass security access checks and leave the system vulnerable to remote attacks. For more information on these Java APIs please refer to Guideline 9 of The Secure Coding Guidelines for the Java Programming Language.
References
[1] Secure Coding Guidelines for the Java Programming Language, Version 4.0
desc.dataflow.java.unsafe_reflection
Abstract
Attackers are able to control an argument to the
performSelector method which could allow them to create unexpected control flow paths through the application, potentially bypassing security checks.Explanation
If an attacker can supply values that the application then uses to determine which class to instantiate or which method to invoke, the potential exists for the attacker to create control flow paths through the application that were not intended by the application developers. This attack vector may allow the attacker to bypass authentication or access control checks or otherwise cause the application to behave in an unexpected manner.
Example 1: A common reason that programmers use the selector API is to implement their own command dispatcher. The following example shows a Objective-C command dispatcher that uses reflection to execute an arbitrary method identified by a value read from a custom URL scheme request. This implementation allows an attacker to call any function matching the method signature defined in the
Example 1: A common reason that programmers use the selector API is to implement their own command dispatcher. The following example shows a Objective-C command dispatcher that uses reflection to execute an arbitrary method identified by a value read from a custom URL scheme request. This implementation allows an attacker to call any function matching the method signature defined in the
UIApplicationDelegate class.
...
- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url
sourceApplication:(NSString *)sourceApplication annotation:(id)annotation {
NSString *query = [url query];
NSString *pathExt = [url pathExtension];
[self performSelector:NSSelectorFromString(pathExt) withObject:query];
...
desc.dataflow.objc.unsafe_reflection
Abstract
An attacker may be able to create unexpected control flow paths through the application, potentially bypassing security checks.
Explanation
If an attacker can supply values that the application then uses to determine which class to instantiate or which method to invoke, the potential exists for the attacker to create control flow paths through the application that were not intended by the application developers. This attack vector may allow the attacker to bypass authentication or access control checks or otherwise cause the application to behave in an unexpected manner. Even the ability to control the arguments passed to a given method or constructor may give a wily attacker the edge necessary to mount a successful attack.
This situation becomes a doomsday scenario if the attacker may upload files into a location that appears on the application's classpath or add new entries to the application's classpath. Under either of these conditions, the attacker may use reflection to introduce new, presumably malicious, behavior into the application.
Example: A common reason that programmers use the reflection API is to implement their own command dispatcher. The following example shows a command dispatcher that does not use reflection:
A programmer might refactor this code to use reflection as follows:
The refactoring initially appears to offer a number of advantages. There are fewer lines of code, the
However, the refactoring allows an attacker to instantiate any object that implements the
One way to address this access control problem is to make the
Although this is an improvement, it encourages a decentralized approach to access control, which makes it easier for programmers to make access control mistakes.
This code also highlights another security problem with using reflection to build a command dispatcher. An attacker may invoke the default constructor for any kind of object. In fact, the attacker is not even constrained to objects that implement the
This situation becomes a doomsday scenario if the attacker may upload files into a location that appears on the application's classpath or add new entries to the application's classpath. Under either of these conditions, the attacker may use reflection to introduce new, presumably malicious, behavior into the application.
Example: A common reason that programmers use the reflection API is to implement their own command dispatcher. The following example shows a command dispatcher that does not use reflection:
$ctl = $_GET["ctl"];
$ao = null;
if (ctl->equals("Add")) {
$ao = new AddCommand();
} else if ($ctl.equals("Modify")) {
$ao = new ModifyCommand();
} else {
throw new UnknownActionError();
}
$ao->doAction(request);
A programmer might refactor this code to use reflection as follows:
$ctl = $_GET["ctl"];
$args = $_GET["args"];
$cmdClass = new ReflectionClass(ctl . "Command");
$ao = $cmdClass->newInstance($args);
$ao->doAction(request);
The refactoring initially appears to offer a number of advantages. There are fewer lines of code, the
if/else blocks have been entirely eliminated, and it is now possible to add new command types without modifying the command dispatcher.However, the refactoring allows an attacker to instantiate any object that implements the
Worker interface. If the command dispatcher is still responsible for access control, then whenever programmers create a new class that implements the Worker interface, they must remember to modify the dispatcher's access control code. If they fail to modify the access control code, then some Worker classes will not have any access control.One way to address this access control problem is to make the
Worker object responsible for performing the access control check. An example of the re-refactored code is as follows:
$ctl = $_GET["ctl"];
$args = $_GET["args"];
$cmdClass = new ReflectionClass(ctl . "Command");
$ao = $cmdClass->newInstance($args);
$ao->checkAccessControl(request);
ao->doAction(request);
Although this is an improvement, it encourages a decentralized approach to access control, which makes it easier for programmers to make access control mistakes.
This code also highlights another security problem with using reflection to build a command dispatcher. An attacker may invoke the default constructor for any kind of object. In fact, the attacker is not even constrained to objects that implement the
Worker interface; the default constructor for any object in the system can be invoked. If the object does not implement the Worker interface, a ClassCastException will be thrown before the assignment to $ao, but if the constructor performs operations that work in the attacker's favor, the damage will have already been done. Although this scenario is relatively benign in simple applications, in larger applications where complexity grows exponentially it is not unreasonable to assume that an attacker could find a constructor to leverage as part of an attack.desc.dataflow.php.unsafe_reflection
Abstract
An attacker may be able to create unexpected control flow paths through the application, potentially bypassing security checks.
Explanation
If an attacker can supply values that the application then uses to determine which class to instantiate or which method to invoke, the potential exists for the attacker to create control flow paths through the application that were not intended by the application developers. This attack vector may allow the attacker to bypass authentication or access control checks or otherwise cause the application to behave in an unexpected manner. Even the ability to control the arguments passed to a given method or constructor may give a wily attacker the edge necessary to mount a successful attack.
This situation becomes a doomsday scenario if the attacker may upload files into a location that appears on the application's classpath or add new entries to the application's classpath. Under either of these conditions, the attacker may use reflection to introduce new, presumably malicious, behavior into the application.
This situation becomes a doomsday scenario if the attacker may upload files into a location that appears on the application's classpath or add new entries to the application's classpath. Under either of these conditions, the attacker may use reflection to introduce new, presumably malicious, behavior into the application.
desc.dataflow.python.unsafe_reflection
Abstract
An attacker may be able to create unexpected control flow paths through the application, potentially bypassing security checks.
Explanation
If an attacker can supply values that the application then uses to determine which class to instantiate or which method to invoke, the potential exists for the attacker to create control flow paths through the application that were not intended by the application developers. This attack vector may allow the attacker to bypass authentication, bypass access control checks, or otherwise cause the application to behave in an unexpected manner. Even the ability to control the arguments passed to a given method or constructor may give a wily attacker the edge necessary to mount a successful attack.
This situation becomes a doomsday scenario if the attacker may upload files into a location that appears on the application's load path or add new entries to the application's load path. Under either of these conditions, the attacker may use reflection to introduce new, presumably malicious, behavior into the application.
Example: A common reason that programmers use reflection is to implement their own command dispatcher. The following example shows a command dispatcher that does not use reflection:
A programmer might refactor this code to use reflection as follows:
The refactoring initially appears to offer a number of advantages. There are fewer lines of code, the
However, the refactoring allows an attacker to run any method ending with the word "Command". If the command dispatcher is still responsible for access control, then whenever programmers create a new method ending with "Command", they must remember to modify the dispatcher's access control code. Even then, common practice when you have multiple methods similarly named can be to either have these dynamically created using
This situation becomes a doomsday scenario if the attacker may upload files into a location that appears on the application's load path or add new entries to the application's load path. Under either of these conditions, the attacker may use reflection to introduce new, presumably malicious, behavior into the application.
Example: A common reason that programmers use reflection is to implement their own command dispatcher. The following example shows a command dispatcher that does not use reflection:
ctl = req['ctl']
if ctl=='add'
addCommand(req)
elsif ctl=='modify'
modifyCommand(req)
else
raise UnknownCommandError.new
end
A programmer might refactor this code to use reflection as follows:
ctl = req['ctl']
ctl << "Command"
send(ctl)
The refactoring initially appears to offer a number of advantages. There are fewer lines of code, the
if/else blocks have been entirely eliminated, and it is now possible to add new command types without modifying the command dispatcher.However, the refactoring allows an attacker to run any method ending with the word "Command". If the command dispatcher is still responsible for access control, then whenever programmers create a new method ending with "Command", they must remember to modify the dispatcher's access control code. Even then, common practice when you have multiple methods similarly named can be to either have these dynamically created using
define_method(), or may be called via overriding of missing_method(). Auditing and keeping track of these and how access control code is used with these is very difficult, and when considering this would also depend on what other library code is loaded may make this this a near insurmountable task to do correctly in this manner.desc.dataflow.ruby.unsafe_reflection
Abstract
An attacker may be able to create unexpected control flow paths through the application, potentially bypassing security checks.
Explanation
If an attacker can supply values that the application then uses to determine which class to instantiate or which method to invoke, the potential exists for the attacker to create control flow paths through the application that were not intended by the application developers. This attack vector may allow the attacker to bypass authentication or access control checks or otherwise cause the application to behave in an unexpected manner. Even the ability to control the arguments passed to a given method or constructor may give a wily attacker the edge necessary to mount a successful attack.
This situation becomes a doomsday scenario if the attacker may upload files into a location that appears on the application's classpath or add new entries to the application's classpath. Under either of these conditions, the attacker may use reflection to introduce new, presumably malicious, behavior into the application.
Example: A common reason that programmers use the reflection API is to implement their own command dispatcher. The following example shows a command dispatcher that uses reflection:
The refactoring initially appears to offer a number of advantages. There are fewer lines of code, the
However, the refactoring allows an attacker to instantiate any object that implements the
One way to address this access control problem is to make the
Although this is an improvement, it encourages a decentralized approach to access control, which makes it easier for programmers to make access control mistakes.
This code also highlights another security problem with using reflection to build a command dispatcher. An attacker may invoke the default constructor for any kind of object. In fact, the attacker is not even constrained to objects that implement the
Access checks may also be compromised further down the code execution chain, if certain Java APIs that perform tasks using the immediate caller's class loader check, are invoked on untrusted objects returned by reflection calls. These Java APIs bypass the SecurityManager check that ensures all callers in the execution chain have the requisite security permissions. Care should be taken to ensure these APIs are not invoked on the untrusted objects returned by reflection as they can bypass security access checks and leave the system vulnerable to remote attacks. For more information on these Java APIs please refer to Guideline 9 of The Secure Coding Guidelines for the Java Programming Language.
This situation becomes a doomsday scenario if the attacker may upload files into a location that appears on the application's classpath or add new entries to the application's classpath. Under either of these conditions, the attacker may use reflection to introduce new, presumably malicious, behavior into the application.
Example: A common reason that programmers use the reflection API is to implement their own command dispatcher. The following example shows a command dispatcher that uses reflection:
def exec(ctl: String) = Action { request =>
val cmdClass = Platform.getClassForName(ctl + "Command")
Worker ao = (Worker) cmdClass.newInstance()
ao.doAction(request)
...
}
The refactoring initially appears to offer a number of advantages. There are fewer lines of code, the
if/else blocks have been entirely eliminated, and it is now possible to add new command types without modifying the command dispatcher.However, the refactoring allows an attacker to instantiate any object that implements the
Worker interface. If the command dispatcher is still responsible for access control, then whenever programmers create a new class that implements the Worker interface, they must remember to modify the dispatcher's access control code. If they fail to modify the access control code, then some Worker classes will not have any access control.One way to address this access control problem is to make the
Worker object responsible for performing the access control check. An example of the re-refactored code is as follows:
def exec(ctl: String) = Action { request =>
val cmdClass = Platform.getClassForName(ctl + "Command")
Worker ao = (Worker) cmdClass.newInstance()
ao.checkAccessControl(request);
ao.doAction(request)
...
}
Although this is an improvement, it encourages a decentralized approach to access control, which makes it easier for programmers to make access control mistakes.
This code also highlights another security problem with using reflection to build a command dispatcher. An attacker may invoke the default constructor for any kind of object. In fact, the attacker is not even constrained to objects that implement the
Worker interface; the default constructor for any object in the system can be invoked. If the object does not implement the Worker interface, a ClassCastException will be thrown before the assignment to ao, but if the constructor performs operations that work in the attacker's favor, the damage will have already been done. Although this scenario is relatively benign in simple applications, in larger applications where complexity grows exponentially it is not unreasonable to assume that an attacker could find a constructor to leverage as part of an attack.Access checks may also be compromised further down the code execution chain, if certain Java APIs that perform tasks using the immediate caller's class loader check, are invoked on untrusted objects returned by reflection calls. These Java APIs bypass the SecurityManager check that ensures all callers in the execution chain have the requisite security permissions. Care should be taken to ensure these APIs are not invoked on the untrusted objects returned by reflection as they can bypass security access checks and leave the system vulnerable to remote attacks. For more information on these Java APIs please refer to Guideline 9 of The Secure Coding Guidelines for the Java Programming Language.
References
[1] Secure Coding Guidelines for the Java Programming Language, Version 4.0
desc.dataflow.scala.unsafe_reflection
Abstract
Attackers are able to control an argument to the
performSelector method which could allow them to create unexpected control flow paths through the application, potentially bypassing security checks.Explanation
If an attacker can supply values that the application then uses to determine which class to instantiate or which method to invoke, the potential exists for the attacker to create control flow paths through the application that were not intended by the application developers. This attack vector may allow the attacker to bypass authentication or access control checks or otherwise cause the application to behave in an unexpected manner.
Example 1: A common reason that programmers use the selector API is to implement their own command dispatcher. The following example shows a Swift command dispatcher that uses reflection to execute an arbitrary method identified by a value read from a custom URL scheme request. This implementation allows an attacker to call any function matching the method signature defined in the
Example 1: A common reason that programmers use the selector API is to implement their own command dispatcher. The following example shows a Swift command dispatcher that uses reflection to execute an arbitrary method identified by a value read from a custom URL scheme request. This implementation allows an attacker to call any function matching the method signature defined in the
UIApplicationDelegate class.
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let query = url.query
let pathExt = url.pathExtension
let selector = NSSelectorFromString(pathExt!)
performSelector(selector, withObject:query)
...
}
desc.dataflow.swift.unsafe_reflection
Abstract
An attacker may be able to create unexpected control flow paths through the application, potentially bypassing security checks.
Explanation
If an attacker can supply values that the application then uses to determine which class to instantiate or which method to invoke, the potential exists for the attacker to create control flow paths through the application that were not intended by the application developers. This attack vector may allow the attacker to bypass authentication or access control checks or otherwise cause the application to behave in an unexpected manner. Even the ability to control the arguments passed to a given method or constructor may give a wily attacker the edge necessary to mount a successful attack.
Example: A common reason that programmers utilize CallByName is to implement their own command dispatcher. The following example shows a command dispatcher that does not utilize the CallByName function:
A programmer might refactor this code to use reflection as follows:
The refactoring initially appears to offer a number of advantages. There are fewer lines of code, the
However, the refactoring allows an attacker to invoke any method implemented by the
One way to address this access control problem is to make the
Although this is an improvement, it encourages a decentralized approach to access control, which makes it easier for programmers to make access control mistakes.
Example: A common reason that programmers utilize CallByName is to implement their own command dispatcher. The following example shows a command dispatcher that does not utilize the CallByName function:
...
Dim ctl As String
Dim ao As new Worker
ctl = Request.Form("ctl")
If String.Compare(ctl,"Add") = 0 Then
ao.DoAddCommand Request
Else If String.Compare(ctl,"Modify") = 0 Then
ao.DoModifyCommand Request
Else
App.EventLog "No Action Found", 4
End If
...
A programmer might refactor this code to use reflection as follows:
...
Dim ctl As String
Dim ao As Worker
ctl = Request.Form("ctl")
CallByName ao, ctl, vbMethod, Request
...
The refactoring initially appears to offer a number of advantages. There are fewer lines of code, the
if/else blocks have been entirely eliminated, and it is now possible to add new command types without modifying the command dispatcher.However, the refactoring allows an attacker to invoke any method implemented by the
Worker object. If the command dispatcher is still responsible for access control, then whenever programmers create a new method within the Worker class, they must remember to modify the dispatcher's access control code. If they fail to modify the access control code, then some Worker methods will not have any access control.One way to address this access control problem is to make the
Worker object responsible for performing the access control check. An example of the re-refactored code is as follows:
...
Dim ctl As String
Dim ao As Worker
ctl = Request.Form("ctl")
If ao.checkAccessControl(ctl,Request) = True Then
CallByName ao, "Do" & ctl & "Command", vbMethod, Request
End If
...
Although this is an improvement, it encourages a decentralized approach to access control, which makes it easier for programmers to make access control mistakes.
desc.dataflow.vb.unsafe_reflection