@@ -25,7 +25,7 @@ inputs, or avoid constructing code in the first place.
25
25
26
26
<example >
27
27
<p >
28
- The following example shows two methods implemented using ` eval` : a simple
28
+ The following example shows two methods implemented using < code > eval</ code > : a simple
29
29
deserialization routine and a getter method.
30
30
If untrusted inputs are used with these methods,
31
31
then an attacker might be able to execute arbitrary code on the system.
@@ -35,14 +35,37 @@ then an attacker might be able to execute arbitrary code on the system.
35
35
36
36
<p >
37
37
To avoid this problem, either properly document that the function is potentially
38
- unsafe, or use an alternative solution such as ` JSON.parse` or another library, like in the examples below,
38
+ unsafe, or use an alternative solution such as < code > JSON.parse</ code > or another library, like in the examples below,
39
39
that does not allow arbitrary code to be executed.
40
40
</p >
41
41
42
42
<sample src =" examples/UnsafeCodeConstructionSafe.rb" />
43
43
44
44
</example >
45
45
46
+ <example >
47
+ <p >
48
+ As another example, consider the below code which dynamically constructs
49
+ a class that has a getter method with a custom name.
50
+ </p >
51
+
52
+ <sample src =" examples/UnsafeCodeConstruction2.rb" />
53
+
54
+ <p >
55
+ The example dynamically constructs a string which is then executed using <code >module_eval</code >.
56
+ This code will break if the specified name is not a valid Ruby identifier, and
57
+ if the value is controlled by an attacker, then this could lead to code injection.
58
+ </p >
59
+
60
+ <p >
61
+ A more robust implementation, that is also immune to code injection,
62
+ can be made by using <code >module_eval</code > with a block and using <code >define_method</code >
63
+ to define the getter method.
64
+ </p >
65
+
66
+ <sample src =" examples/UnsafeCodeConstruction2Safe.rb" />
67
+ </example >
68
+
46
69
<references >
47
70
<li >
48
71
OWASP:
0 commit comments