|
Coding Security | |
Security is very important, and I'm only going to make a brief coverage of it because it is covered well in Ambryl's MUSH Manual.
Security is important on a MUSH for the same reason your house's security is important to you. You don't want other people breaking in and messing with your stuff.
An argument you sometimes hear against someone securing their code is the following; "Well the object doesn't have any special privs so I don't need to secure it, right?" Wrong, very wrong. Just because it "doesn't have any special privs" doesn't mean that it doesn't. Players objects can set stuff on the player, and merrily @create away. If your code isn't secure, on an unprivlaged wiz-owned object, it isn't too hard to get a wizard object made.
The easiest and simplest way to secure user input is to run it through the secure() function. For example;
&set_attrib me=$set *:&attrib me=%0;@pemit %#=Attrib set to [v(attrib)]/[u(attrib)].can be easily secured by adding a secure() function:
&set_attrib me=$set *:&attrib me=secure(%0);@pemit %#=Attrib set to [v(attrib)]/[u(attrib)].
There is only one problem here, if you want to make sure you do save ()s and other special characters that secure() removes, you need an alternate method.
So you've got an application where you don't want to use secure() but you still want your code to be secure. Probably the safest way of doing this is with the following little trick:
&set_attrib me=$set *:&attrib me=X %0;@pemit %#=Attrib set to [rest(v(attrib))]/[rest(u(attrib))].That effectivally solves the problem in setting, but still leaves the second half of the pemit open to attack. That u() will run any functions in the attrib, so my suggestion is DON'T USE IT ON PLAYER-SETTABLE DATA THAT HASN"T BEEN RUN THROUGH SECURE() or ESCAPE()!
 |
Home | MUSH | Theory | Sitemap | |