Dash not permitted in a message

[medicjoe95]

Hyphens are allowed, but only when operating as a hyphen. Dashes are not. I understand that a dash is crucial part of a sql injection, but in reality the injection requires other banned characters. Thereby, because a dash is at least a legitimate syntactical aspect of the English language, it should be permitted.

My two cents.

Or, at least add in the error alert that dashes are prohibited, because I literally spent like 10 minutes trying to figure out why a message was not going through.

[Engel]

Just stating my two cents on this (only it's kind of different), I'd like to use the = sign. That way you can say = or send someone =) instead of

I don't know. I wish it was open to a lot of other symbols.

[raskull]

Banning characters is a pretty crappy way of avoiding injection attacks. Any programmer worth his salt should be able to properly escape/htmlencode things where necessary. Of course, I've done the same thing in a pinch (and the customer also complained) so I guess I really shouldn't be calling the kettle black...

[admin]

Thanks for the report. I was unaware that the message screen was still doing this. The issue has been corrected.

[medicjoe95]

Banning characters is a pretty crappy way of avoiding injection attacks. Any programmer worth his salt should be able to properly escape/htmlencode things where necessary. Of course, I've done the same thing in a pinch (and the customer also complained) so I guess I really shouldn't be calling the kettle black...

:/

You're forgetting that a user can run the exploit before it is escaped... hence why its called an injection. The only legitimate way to prohibit this is to run a filter before the script/injection is processed. The CN Admins are doing what they should be doing :/

I think you may be getting PHP-based and ASP-based injections mixed up.

Nonetheless, thank you Admin

[raskull]

:/

You're forgetting that a user can run the exploit before it is escaped... hence why its called an injection. The only legitimate way to prohibit this is to run a filter before the script/injection is processed. The CN Admins are doing what they should be doing :/

This is getting a little OT (mods feel free to close), but what? The user can't run anything, all they can do is hope they can con the server into running it for them. That is an injection attack. The way to prevent that is to properly escape all user input before using it in exploitable contexts. This doesn't require filtering the data (although, this often is the easy way out, at the expense of functionality).

I think you may be getting PHP-based and ASP-based injections mixed up.

I don't see why the language is relevant. I'm just talking in generalities. Anyway the vast majority of injection attacks (SQL) don't depend on any particular features of either ASP or PHP.

[admin]

Closing this. Medicjoe95 and raskull can debate about this via PM.