User Tools

Site Tools



This shows you the differences between two versions of the page.

Link to this comparison view

xeval [2010/05/12 22:25] (current)
Line 1: Line 1:
 +[[xeval]] //[see flags below]// //<​block>//​
 +The [[xeval]] command runs the //<​block>//​ of code after it has gone through
 +alias expansion again.  ​
 +INJECTION ATTACK.** ​ This can't be stressed strongly enough.
 +=====Safe uses:=====
 +  - At the input prompt, when you want to use a variable value
 +  - When you have stored trusted code, in a variable and you want to run it
 +  - When you have surrounded //<​block>//​ in curly braces ("​{"​ and "​}"​)
 +This can't be stressed strongly enough.
 +====At the input line====
 +Let's say you have a variable whose value you want to pass to a command.
 +Ordinarily you can't do that because the input line is handled literally
 +and your $'s don't expand. ​ You can use [[xeval]] to for $'s to expand
 +at the input line.
 +===Example of expanding variables at the input line:===
 +  /assign myvar isn't this neat?
 +  /xeval say This string contains a variable which will expand -> $myvar
 +====When you have code stored in a variable====
 +According to the language syntax, after a statement is removed from a block,
 +it is subject to $ expansion and then executed. ​ This means that characters
 +that are part of the syntax (such as ";"​) are treated literally and do not
 +act as statement separators.
 +====Example of converting strings into code:====
 +  @ mycode = 'echo hi there!;join #epic'
 +  xeval -- $mycode
 +====When you have surrounded block with curly braces====
 +When dealing with untrusted strings, you want to make sure they don't get
 +parsed as statements. ​ The effect of curly braces is the reverse of [[xeval]]
 +so if you wrap //<​block>//​ in curly braces, untrusted strings cannot be 
 +treated as code:
 +===Example of using curly braces to prevent untrusted strings:===
 +  on msg * {xeval -w MsgWin {echo $*}}
 +=====Unsafe uses:=====
 +  - To double-expand a variable
 +  - When used with any string you received anywhere but the user
 +====Examples of unsafe uses:====
 +===Double expanding a variable===
 +   @ foo = '​$bar'​
 +   @ bar = '​testing'​
 +   xeval echo $foo
 +That doesn'​t look so bad, does it?  But what happens if someone does:
 +   @ bar = '​testing;​exec rm -rf ~'
 +That leads to:
 +   xeval echo testing;​exec rm -rf ~
 +If you want to double expand a variable or string, use the %%**%% operator
 +   echo ${**foo}
 +====When used on any unsafe string====
 +An unsafe string is any string received from anywhere except the user at
 +the input line or from the file that the user [[load]]ed. ​ Particularly,​
 +any string received from irc.
 +   on msg * {xeval -w MsgWin xecho -b Msg from $*}
 +This is an injection attack because if msg you "​testing;​exec rm -rf ~"
 +then the above command becomes:
 +   xeval -w MsgWin echo testing;​exec rm -rf ~
 +Whenever you are dealing with an untrusted string, always wrap the command
 +in curly braces when using [[xeval]]. ​ The above code could be safely written
 +   on msg * {xeval -w MsgWin {xecho -b Msg from $*}}
 +| -server <server desc> | Change from_server to the given server. |
 +| -window <window desc> | Change current_window to the given window. |
 +| -noisy ​               | Reverse the effect of %%^%% on statements |
 +| --                    | (Two dashes) End option processing. ​ The //block// begins immediately after this option. |
 +It's possible to set //-server// and //-window// independantly of each 
 +other, which allows you to do crazy things like setting the current window
 +to a window whose server is not the same as //​-server//​. ​ Best practice is
 +to always set them both, and to ensure that the //-server// is set to the
 +server that //-window// belongs to.
 +The original server and window settings are restored before returning, so 
 +[[xeval]]ing a command that changes the current window or server will appear
 +to have no effect.
xeval.txt ยท Last modified: 2010/05/12 22:25 (external edit)