I've been coding for over 20 years now! (WOAH, do I feel old)
I've touched just about every resource imaginable under the Sun (too bad they were bought out by Oracle)
Due to the security nature of dealing with SQL Injection and Cross Site Scripting mitigations, I'm just going to flat out say that the code above is wrong. Normally, I wouldn't, but, I really REALLY don't want someone to copy that code and get exploited.
A couple points.
1) the mysql_ functions in PHP were removed many years ago. They're highly problematic. They should never be used. mysqli_ functions should be used instead.
2) magic quotes was also removed many years ago too. Don't rely on them, they don't exist now, due to all the issues surrounding them.
3) don't intermix strip_slashes and any of the _escape_string functions, this is just leading into disaster with mangling data, potentially causing unforeseen problems.
4) PHP has a strip_tags function built in. Use theirs, don't re-implement it, or else prepare for it to be abused and exploited by missing some subtleties in how HTML/XML work. A regex is never a good way to parse/strip HTML.
5) stripping and <style> are redundant, since they're all HTML tags, which are already being stripped.</p>
<p>6) this implementation takes the false assumption that "bad data" comes from SOME external sources only ($_GET and $_POST). There are other external sources, such as $_REQUEST and $_FILE. But more importantly, there are also INTERNAL sources of data. It very much is possible for data to be written to the database, read back for processing, and then written back to the database, and in that process, become exploitable data. If it was escaped going in, then it needs to be re-escaped to go in again the next time too.</p>
<p>I'd <em>HIGHLY</em> recommend just using a database connection and processing library that handles all of this securely for you, so you don't have to think about it anymore, such as PUDL: <a href="https://github.com/darkain/pudl" rel="nofollow">https://github.com/darkain/pudl</a></p>
I've been coding for over 20 years now! (WOAH, do I feel old)
I've touched just about every resource imaginable under the Sun (too bad they were bought out by Oracle)
Looks like my comment is a GREAT EXAMPLE of how things could get mangled from improper sanitation and validation! LMAO. Time to go file a bug with dev.to
Due to the security nature of dealing with SQL Injection and Cross Site Scripting mitigations, I'm just going to flat out say that the code above is wrong. Normally, I wouldn't, but, I really REALLY don't want someone to copy that code and get exploited.
A couple points.
1) the mysql_ functions in PHP were removed many years ago. They're highly problematic. They should never be used. mysqli_ functions should be used instead.
2) magic quotes was also removed many years ago too. Don't rely on them, they don't exist now, due to all the issues surrounding them.
3) don't intermix strip_slashes and any of the _escape_string functions, this is just leading into disaster with mangling data, potentially causing unforeseen problems.
4) PHP has a strip_tags function built in. Use theirs, don't re-implement it, or else prepare for it to be abused and exploited by missing some subtleties in how HTML/XML work. A regex is never a good way to parse/strip HTML.
5) stripping and <style> are redundant, since they're all HTML tags, which are already being stripped.</p> <p>6) this implementation takes the false assumption that "bad data" comes from SOME external sources only ($_GET and $_POST). There are other external sources, such as $_REQUEST and $_FILE. But more importantly, there are also INTERNAL sources of data. It very much is possible for data to be written to the database, read back for processing, and then written back to the database, and in that process, become exploitable data. If it was escaped going in, then it needs to be re-escaped to go in again the next time too.</p> <p>I'd <em>HIGHLY</em> recommend just using a database connection and processing library that handles all of this securely for you, so you don't have to think about it anymore, such as PUDL: <a href="https://github.com/darkain/pudl" rel="nofollow">https://github.com/darkain/pudl</a></p>
Looks like my comment is a GREAT EXAMPLE of how things could get mangled from improper sanitation and validation! LMAO. Time to go file a bug with dev.to
Thank you for your comments, hopefully those who read can get the benefits.