Sharing .mis files: Safety First
by Andrew Haydn Grant · in Torque Game Engine · 01/24/2006 (12:23 am) · 2 replies
I would like players to be able to share custom mission files. In order to ensure that this is safe for all the users who download mission files, I'd like each mission file to go through a verification process.
I think I need to write a parser that detects any interesting code in a mission file. If the file contains anything outside of a MissionGroup declaration, or if the declaration includes any function calls, or if the declaration creates any dangerous object types, it should be rejected.
I'm not entirely sure which objects should be considered dangerous, though. All the GUIControls (with their arbitrary script commands) would seem to qualify.
So the big question is, "What am I missing?"
(And if the answer is, "This resource over *here*," that'd be grand. ;-) )
I think I need to write a parser that detects any interesting code in a mission file. If the file contains anything outside of a MissionGroup declaration, or if the declaration includes any function calls, or if the declaration creates any dangerous object types, it should be rejected.
I'm not entirely sure which objects should be considered dangerous, though. All the GUIControls (with their arbitrary script commands) would seem to qualify.
So the big question is, "What am I missing?"
(And if the answer is, "This resource over *here*," that'd be grand. ;-) )
About the author
#2
I am reluctant to bar semi-colons from the field data; sometimes a semi-colon is just the punctuation that you want in your flavor text.
Hmm. Maybe one easy way to do this would be to write a very simple & paranoid parser, much like you describe, and push all the FAIL results to a human for review. When I see a lot of similar false negatives, I can code to allow that one case. (For example, say, semi-colons in the MissionInfo.desc0 field value).
Human review of all FAIL results would be good anyway, so I'd know if someone out there was being evil.
Human review of all PASS results would be even better, and makes sense when the volume is low.
01/24/2006 (11:38 pm)
Good thoughts. I can certainly reject any file that contains anything outside of the normal typewriter keys, which is a good one I'd missed. No binary data, please!I am reluctant to bar semi-colons from the field data; sometimes a semi-colon is just the punctuation that you want in your flavor text.
Hmm. Maybe one easy way to do this would be to write a very simple & paranoid parser, much like you describe, and push all the FAIL results to a human for review. When I see a lot of similar false negatives, I can code to allow that one case. (For example, say, semi-colons in the MissionInfo.desc0 field value).
Human review of all FAIL results would be good anyway, so I'd know if someone out there was being evil.
Human review of all PASS results would be even better, and makes sense when the volume is low.
Associate Manoel Neto
Default Studio Name
So you'd write a list of all object types you allow in your mission to check "new" declarations. That's the easy part. I'd also check if the new declarations is properly written (no extra parenthesis, no funny stuff in the object names - like function calls, global variables or other object fields).
The harder part is filtering field data. Someone could easily stick function calls in there. I'd do an iron-hand check on it's formatting:
And declare it invalid if
- Funny stuff in field name (anything not alpha-numeric and not "-" nor "[" or "]");
- Funny stuff in field data (it MUST be betwen quotes, and if it's a file path, check if the file exists)
- More than one semi-colon.