Both cases are serious vulnerabilities, and the security approach is wrong.
First of all, the form itself shouldn't escape anything. You might want to check the input, but you do not manipulate it. Escaping is done in a specific context like a database query, not globally.
No, it's not secure to simply prepend a backslash to single quotes in the application:
- Database systems support different character encodings which may or may not match the encoding used by your application. If they don't match, the escaping attempt is essentially a shot in the dark and may not work at all. There's a famous injection attack which exploits the differences between two common character encodings. The only way to be sure is to use an encoding-aware library function of your database system. For example, MySQL has
- Backslash-escaping is a nonstandard mechanism which only works in some special modes of some database systems (like MySQL). If the server configuration or the underlying database change, you may again lose all protection.
- There are much more characters that you need to take care of. This also depends on the database system and its configuration.
Manual SQL-escaping is actually a rather poor approach, because it's complicated, tedious and error-prone (as you can see). A more modern solution is to use prepared statements and not stuff any user data into SQL queries in the first place. If, for some reason, prepared statements are not an option, make sure to use the right library function instead of trying to invent your own solution.
Your second case is a full-blown cross-site scripting vulnerability, so an attacker can do anything which is possible with XSS (like stealing a session cookie). No, XSS is not limited to URLs in any way. You've just proved that yourself. An XSS attack happens when a user is able to inject data into an HTML context. Where that data comes from is irrelevant; could be the URL, could be a form paramater, could be a cookie, an HTTP header, a database string, anything.