@@ -25,7 +25,7 @@ inputs, or avoid constructing code in the first place.
2525
2626<example >
2727<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
2929deserialization routine and a getter method.
3030If untrusted inputs are used with these methods,
3131then 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.
3535
3636<p >
3737To 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,
3939that does not allow arbitrary code to be executed.
4040</p >
4141
4242<sample src =" examples/UnsafeCodeConstructionSafe.rb" />
4343
4444</example >
4545
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+
4669<references >
4770<li >
4871OWASP:
0 commit comments