Jump to content

Dash not permitted in a message


medicjoe95
 Share

Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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 :)

Link to comment
Share on other sites

:/

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.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...