Suggestion on handling input() calls to prevent injection

[Erik]

I might have mentioned this on IRC before, but it might be a good thing to consider looking at the amount of string sanization bugs i reported to various coders over the few weeks, and considering the human factor, it will most likely happen again.

The possible solutions for this, should both be quite easy to implement, and maintain.. And should most likely prevent future issues with string sanitation.

• Create a preprocessor macro to replace input() with safe_input()
  
• Run a find/replace and replace input() with safe_input()

This can also be a total shit suggestion, maybe i shouldnt submit suggestions at 8AM while being super sleepy, heh.

[Marquesas]

This is literally impossible though, since the syntax of input is

Code:

input(usr, message, title, default) as Type in List

which is a syntax that you cannot use for custom procs.


Obligatory out of context quote

This can also be a total shit suggestion, maybe i shouldnt submit suggestions

[Erik]

Well, out of context quotes are rude hey!

This is literally impossible though, since the syntax of input is

Mostly true, this just elimitates the usage of a preprocessor macro to replace input() with another proc!

Most places where you use these kinds of statements, are completely fine, since the trouble happens in other input() calls

Code:

input("Select a gender for your character.","Your Gender",usr.gender) in list("male","female","neuter")

Like this one, so a simple find/replace would solve all, standing.. and missing issues but yeah and all that crap

Code:

usr.name = input("Choose a name for your character.","Your Name",usr.name)

Another solution would be to manually verify all input() calls, and verify that they use a proper way of sanitizing the output, or we just wait for lummox to implement it into the engine. http://www.byond.com/forum/?post=1913933

[Marquesas]

Types that input expects cannot be held in arguments, variables, whatever and then used as a parameter to input. It's important we don't omit that bit since it defines the type of window you get (file input window, text input window, numeric input window, color picker, and so on). We could make a special case only for text; sure, I'm not sure about the benefit of using "text_input()" for unrestricted textual input and "input() as buttplug" for every other type.

[Erik]

We could make a special case only for text; sure, I'm not sure about the benefit of using "text_input()" for unrestricted textual input and "input() as buttplug" for every other type.

I'm not sure about the benefit

The benefit is easy, you no longer have issues where people can simply embed anything they want into the game, last time i send a list of exploits to drsingh i had quite a few ways to embed any string length of html, and a few more ways to send them to all clients.

Types that input expects cannot be held in arguments, variables, whatever and then used as a parameter to input. It's important we don't omit that bit since it defines the type of window you get (file input window, text input window, numeric input window, color picker, and so on).

Yup, i'm a idiot, totally forgot about those usages.. but then again replace textual input() calls with something safer and you should fix most currently known problems, and yet to discover problems that allow people to

• Massivly crash clients. (embed youtube videos to instantly crash al clients.)
  
• Force clients to execute href calls (known href calls, or small piece of JS to bruteforce href calls.)
  
• Force clients to execute arbitrary code via the usage of flash 0days. (enough people still play byond on old windows versions, with outdated software..)

[BabaYaga]

Is this thread in English?