This is the St Pancras Renaissance hotel in London - great that they let us film after our original location fell through - shame they wouldn't let me use lights though! >Sean
One of the better 'funny pictures' I have seen, was a numberplate on a pretty fast car, which had an SQL instruction to drop some tables... hello speed cameras ...
"It's a hack on top of a hack.... That's a hack, and we've had to put more on top of that, and more on top of that, and more on top of that." It's a hack stack!
This video is good but makes it sound if a website is poorly coded (so SQL injection is possible) that the database server has no security and is an open platter i.e if a malicious user attempts to run a DELETE, DROP DATABASE command they will be able to do this. If the security on the database side has been granted appropriately the user specified in the connection string of the web application will not be able to execute these commands. All users should only be granted permissions required to do the tasks they are going to use. There is no need for a web application needing to have the DROP ALL DATABASES or similar commands. Not trying to water down the risk just making it clear that the problem lies on the developer (code) and administrator side (permissions).
The correct way to think about this: when you are writing code that generates SQL, you need to generate it according to the SQL syntax. When you inject a string into an SQL statement, you need to convert that string into an "SQL string literal". This is done by adding the quotation marks at the beginning and end and escaping any character that has a different meaning in an SQL string literal than in a plain string (backslashes, quotes, etc...). The SQL syntax specification shows you where these string literals are allowed in a statement. If you are putting an integer into your SQL, you need to convert it to an "SQL integer literal", which is usually done just by converting it to a string. (Not an SQL string literal-just a string.)
Oh this should be some nostalgic fun, I remember back in highschool when injecting some code into a text field and... this video is from 2013. This video is from 2013? This video is from 2013! How in holy hell could ANYONE leave such a vulnerable area of security wide open this long?
Thanks for these videos... In my experience of web programming as an amateur, Security issues have never been something I have come across all that often. It's good to learn more about them.
Really enjoy the lighting and setting of this one. Informative person as well. Seeing a large increase in quality on this channel and it's much appreciated.
I liked this bloke, he's very passionate about the subject which helps him avoid the boredom that can creep in when listening to a talk on programming. Excellent topic too; I'm neck deep in learning PHP at the moment, so I appreciate the heads up about the security risks.
Great video. Had a web interview a few weeks ago where I needed to know what an SQL injection is, and while I did try and explain it with my limited knowledge, I learned a lot more about it from watching this video. Thanks for the upload, and I'd also love to see more of Tom.
Python has taught me really well with strings and escaping. Of course Ive learned more than escaping and learn strings, but I still am thankful for learning it.
or use an api that discourages raw text queries -- which is good practice both for security as well as for interoperability between different database software.
Awesome video! Personally, I think that HTML, Javascript and PHP should be taught in every high school worldwide, if for no other reason than the problem solving skills and understanding of how the internet works gained in the process. No offense to the other client-side and server-side scripting languages.
Firstly, a clarification: MySQL is a program what listens at a certain port for commands. Basically, its like a web-server. A PHP simply has a library what simplifies interaction with mysql program to a bunch of commands. So, PHP and MySQL are two different things, and SQL Injection applies to MySQL not to PHP. As someone who coded on PHP for 4+years, I think that language at its roots is a mess. Only way to make PHP something, is to rewrite everything from a scratch PROPERLY.
Don't most websites send text through some secondary language's, like JS or something, function to clean the input before sending it to the actual database?
The real question in that case is what constitutes "its own program". You can run JavaScript via a browser, but the JavaScript code doesn't have to call browser specific (e.g. DOM) methods. You could (at least theoretically) write a JS code that works equally with a browser or with a server system (e.g. Node.js) or a build system (e.g. Visual Studio's ".w32" files). The language is all the same in all those environments. Only the non-core APIs of the runtime differ.
I am a professional database expert and I know that the language I am a specialist in, DB2, that 2 two things... 1 - This has been a well known security issue for many years, and any DBM or security expert would be fully aware of these specific issues 2 - Even if for whatever reason someone was able to input commands they shouldn't be allowed to input.. 2A - There are restrictions on who is allowed to perform what operations and on which table(s)(and even which individual records). Even if someone was able to hack the command stream and input malicious commands, any reasonable database will have very easy to implement restrictions that make sure nobody could ever do or view anything they aren't supposed to, and CERTAINLY not do any sort of potentially seriously disruptful actions like deleting data or dropping all databases, lol. Just a very simple restriction on any potentially powerful commands to only the database admins would nullify any of these potential threats. 2B - Even IF something catastrophic was performed like "drop all databases" there are methods of restoring the database to previous states, not just by having BACKUPS saved somewhere, but by diagnostic logs that can be used to roll the environment back in time. I suppose it's possible to imagine a malicous attack that was smart enough and all-inclusive enough to delete all backups and relevant data needed to restore the environment, but just keeping a seperate copy of backups on a completely separate system would alleviate that possibility.
Well, adding abstraction on top of another one to cover-up mess, starts to become clumsy. I've switched to C couple years ago, and I never regretted doing it since. With ~1 year of C experience, in couple weeks, I was able to write H T T P server from scratch using sockets and pthreads. In another couple weeks, I had dynamic pages and AJAX going. It looks daunting at first, but unless you try, you'll never know how handcuffed you were with PHP.
No, Jason's right. The problem is "procedural instructions" is too vague a term to use to distinguish anything. It's what *everything* in computer programming boils down to. The "procedural" paradigm is a top-level category that includes several languages, including object-oriented ones. Scripting is just an application, which "extension" is a fine synonym for. Any language can become a scripting language simply by being supported by another program, like browsers have done with JavaScript.
Yeah, I'd never heard about that site. I hit upon W3Schools a while back and was pretty horrified about what I saw being taught as gospel in their tutorials.
SEQUEL was different to SQL and used for ~12 years before the 1986 ANSI spec for SQL, in which the correct pronunciation is specified. It may be that the pronunciation was only even defined to avoid copyright infringement, but since it's in the spec the pronunciation is just as well defined as the "SELECT" keyword, for example. Just as you can't swap "choose" or "find" or "get" for "select" in a query, there is a pronunciation that is defined as correct and other pronunciations are non-spec.
In php and all other modern programming languages the classes and functions to communicate with database are made so well I don't really have to worry about escaping the value. (pdo for example. no idea why would anyone still use mysql or mysqli even)
SQL was designed under the name SEQUEL (Structured English QUEry Language), but Sequel just so happened to be a trademarked name of a UK company called Hawker Siddeley Aircraft so it had to be changed. From that, we can assume both ways of saying are correct since Sequel was the name originally intended but "Es-Kyoo-El" is the amended one.
I'd like to hear more detail about other methods of injections. I've always been under the impression that properly escaping your inputs was enough to be safe...
Of course, in some cases stored procedures/functions can be better, but that often ties you to a particular database/infrastructure stack. It's a trade-off in your overall architecture. Lock yourself in with Stored Procedures, or be a little more flexible (useful in products you want to sell, especially to large businesses/enterprises).
Me and my friend always joked about naming a kid "DropTable" in our IS SQL intro course. But I guess now I realized it should be something along the lines of: Frank";Droptable
And “proper handling” means query parameterization (prepared statements) - which was actually described in this video… But you can’t do it with PHP’s mysql_*, hence the “easier in PHP”.
The recent ‘Super Mario World (1990)’ speedrun uses code injection in very fascinating ways that I don't understand. There is even a way to play PONG on the game using in-game sprites and complicated code injection.
One of additional benefits of database prepared statements is they usually offer a performance boost in returning the data. Not a huge amount mind you, but it adds up. If you need more complexity in database queries than prepared statements can do, than any web application should be using stored procedures. It is this specific point that royally pisses off most web programmers, because they need to learn the internals of something else, and their easy money job just became much more complicated.
On some websites it's intended for you to not be able to save some images or get a popup or have a chance to be redirected instead, when you click on a link. On some lower end websites you can go around all that by looking at the source code. Often there are links in the code that reveal the url of the images or you can figure out how to change the text of the link address (right click -> copy link address) to open it without extra popups.
Just because there is not a compiler from Javascript to machine code, doesn't mean it's not a programming language. The formal definition is more abstract and less practical. Also, there is a compiler language for PHP, take a look for HipHop, which allow you to compile from PHP -> C++ -> Code Machine (and don't tell me that C++ is in the middle, because every compiler makes a lot of “translations” before return the machine code, even the compilers of C++).
Just to make it completely clear, the correct pronunciation is "es queue el". SEQUEL is a different thing. The pronunciation of SQL is defined in its spec and big DBMS (e.g. mysql and even microsoft sql) have also defined their pronunciations as "es queue el" at various stages.
Where most people draw the distinction is a script is interpreted at run time, and a programming language is compiled into a binary before hand. There are many language that blur the line, but thats the general idea.
Good point. All JavaScript execution is done in a JavaScript interpreter, typically written in C. But if you're going to make that distinction, then you might as well say the most common language is x86 machine language.
Great vid !! There is a lot of confusion about prepared statements at the moment. It's more than string building for onwards processing. The SQL statement is parsed and optimised for execution by the RDBMS. The variable is inserted prior to execution by the optimiser. In general, it's a good thing to prepare when you can. Just trust me. Most DBAs will have a large list of their commonly executed statements. It's safer and they gain some element of control over the SQL being executed.
You can easily protect a query like this "SELECT * FROM users WHERE user_id=" . $user_id (where user_id is an integer) by placing "(int)" in front of "$user_id" like "(int)$user_id". This casts the variable "user_id" as an integer. If someone types in something nefarious, it will just be converted into a harmless integer. Prepared statements may be safer but casting is better than nothing and is simple to do.
That's not the "only" reason for the bad rep. There are reasons the good programmers are leaving, and the situation is not improved simply by the existence of newer versions. New features don't fix the older ones, and PHP is notorious for adding features without proper design or consideration of pros and cons, by people who have a poor grasp on the features they are implementing. It's object oriented support is no exception.
SQL is an initialism, as it is properly pronounced "Ess Kew Ell". An acronym is an initalism that is pronounced as a word e.g. RADAR, SONAR, whereas SQL, FBI, PHP, etc. are initalisms as you pronounce the letters individually.
Does limiting the amount of access that the user has using sql permissions, say, in an oracle DB also solve the issue on its own? Say the user that logs in can only select data from the db, and only from certain tables and you deny them the 'drop', 'delete', 'alter' and other dangerous commands. Would that nullify the threat that injections pose? A hacker trying an injection would get back a 'you don't have permission to perform this operation' message, right? In the real world I'm assuming you use setting permissions in conjunction with the other techniques described in the video to make sure your data is 'safe,' not just relying on permissions alone.
You're right. In fact it's the same definition in Merriam Webster as it is in the Oxford Dictionary. However, because it's American perhaps, It doesn't distinguish as much between similar words, in this case initialism or abbreviation. But in England, we're a bit more rigorous with our language. Check out the Oxford Dictionary definition.
I told countless times to the other developer at work to write all the SQL in procedures, and not inline in the application, but he did not listen to me. Now he works in another company, paid better than me. After a security check in my company, all my applications pass clean without errors, and all his applications have errors, and SQL injection problems. Now I have to fix all his applications, to transfer his inline SQL code to procedures. How fun is that !!!
A programming language is a formal language designed to communicate instructions to a machine, particularly a computer. Programming languages can be used to create programs that control the behavior of a machine and/or to express algorithms precisely. JavaScript is a programming language
The thing is, most people don't want to reinvent the wheel. If it works, it works. A whole lot of solutions out there are based on PHP, something other languages don't have. With PHP and a framework like Laravel you can get up and running extremely quickly and get a lot of support, documentation and extensions in that framework. There are no real alternatives to that. If you don't want to build your own backend from scratch, PHP is the way to go for now.
Luckily that's where frameworks come in. They clean up a lot of the mess by abstracting it away. All security features are handled in a consistent manner, all DB access is thoroughly cleaned, etc. Things are getting better though. PHP 5.5 just came out a few months ago with a bunch of really nice features. They are stepping up their game again.
Last time, I just killed every user input that wasn't one of our 26 letters or 10 numbers. Stops SQL injection as well, though I think that would fall under "prepared statements".
This is the St Pancras Renaissance hotel in London - great that they let us film after our original location fell through - shame they wouldn't let me use lights though! >Sean
One of the better 'funny pictures' I have seen, was a numberplate on a pretty fast car, which had an SQL instruction to drop some tables... hello speed cameras ...
Simply: don't ever ever trust user input.
"; DROP ALL DATABASES;
dammmit.
He speaks SO LOUD... lol... I think the entire cafe knows how to hack websites by now...
"It's a hack on top of a hack.... That's a hack, and we've had to put more on top of that, and more on top of that, and more on top of that."
It's a hack stack!
>"You can read people's passwords..."
Well hopefully they're hashed anyway
Tom Scott is awesome! "If you can't explain it to an eight year old, you don't fully understand it yourself!" -Unknown Smart person
One finger: "Facebook was originally written in PHP"
Second finger: All other things.
Nice one.
Description amended to be less PHP specific - he does explain using PHP though, however little the PHP specific content >Sean
I am familiar with SQL injections but it doesn't work on any websites that are worth messing with
"Shouldn't work any more but still does."
Just ask TalkTalk's IT department...
This video is good but makes it sound if a website is poorly coded (so SQL injection is possible) that the database server has no security and is an open platter i.e if a malicious user attempts to run a DELETE, DROP DATABASE command they will be able to do this. If the security on the database side has been granted appropriately the user specified in the connection string of the web application will not be able to execute these commands. All users should only be granted permissions required to do the tasks they are going to use. There is no need for a web application needing to have the DROP ALL DATABASES or similar commands. Not trying to water down the risk just making it clear that the problem lies on the developer (code) and administrator side (permissions).
"It works, but it's clunky." - PHP in nutshell.
I literally came to the video to see if he pronounced it as "sequel" or S.Q.L.
I got my answer instantly! :D
Oh Tom Scott, you always manage to make us feel just a tad bit more paranoid.
The correct way to think about this: when you are writing code that generates SQL, you need to generate it according to the SQL syntax. When you inject a string into an SQL statement, you need to convert that string into an "SQL string literal". This is done by adding the quotation marks at the beginning and end and escaping any character that has a different meaning in an SQL string literal than in a plain string (backslashes, quotes, etc...). The SQL syntax specification shows you where these string literals are allowed in a statement. If you are putting an integer into your SQL, you need to convert it to an "SQL integer literal", which is usually done just by converting it to a string. (Not an SQL string literal-just a string.)
Amazing that he knows I'm a camera, I'm impressed!
Good ol' Bobby Tables.
Oh this should be some nostalgic fun, I remember back in highschool when injecting some code into a text field and... this video is from 2013. This video is from 2013? This video is from 2013! How in holy hell could ANYONE leave such a vulnerable area of security wide open this long?
Love the non ordinary video background. Nicely explained topic. Thank you.
Robert'); DROP TABLE Students;--
Actually I love his passion for the language and the whole subject itself. You can practically see the fire in his eyes. great work helped a bunch
as hacks go there are worse ones *heavy sigh* - There speaks someone who has had to deal with them! I know that sigh all too well.
PHP is only fun at the beginning.
Tom is so passionate about this stuff. It is truly amazing to watch him explain stuff.
This is a really tough thing to explain to non-technical people, and this guy did a great job of it.
Thanks for these videos... In my experience of web programming as an amateur, Security issues have never been something I have come across all that often. It's good to learn more about them.
Just got out of jail because i tried this 5 years ago. THANKS ALOT FOR THE WARNING TOM
Really enjoy the lighting and setting of this one. Informative person as well. Seeing a large increase in quality on this channel and it's much appreciated.
There's a fix for this. It's called not using PHP
"It really shouldn't work anymore, but still does" is the best description of SQL injection I've ever heard.
I liked this bloke, he's very passionate about the subject which helps him avoid the boredom that can creep in when listening to a talk on programming.
Excellent topic too; I'm neck deep in learning PHP at the moment, so I appreciate the heads up about the security risks.
Great video. Had a web interview a few weeks ago where I needed to know what an SQL injection is, and while I did try and explain it with my limited knowledge, I learned a lot more about it from watching this video. Thanks for the upload, and I'd also love to see more of Tom.
funnily enough, I got a SQL course ad for this video.
More of this guy.
I always wonder if the other people in the restaurant (?) cant help but listen in on the riveting conversation going on.
Python has taught me really well with strings and escaping. Of course Ive learned more than escaping and learn strings, but I still am thankful for learning it.
This guy is the most entertaining and easy to learn from guy on computerphile! More please!
I don't understand who dislikes these videos, no matter what there are people who will dislike every video on youtube
Really liked Tom's way of explaining, I too would like to see more of him!
How did you isolate his voice from the surrounding noise?
Going to show this video to our apprentice. He is going to learn SQL in school soon. Best wishes from germany!
"Prepared statements" - this is also called parameterized queries, right?
moar videos with this guy pls, he's amazing; he manage to output such concise information with ease
or use an api that discourages raw text queries -- which is good practice both for security as well as for interoperability between different database software.
Awesome video! Personally, I think that HTML, Javascript and PHP should be taught in every high school worldwide, if for no other reason than the problem solving skills and understanding of how the internet works gained in the process. No offense to the other client-side and server-side scripting languages.
Firstly, a clarification: MySQL is a program what listens at a certain port for commands. Basically, its like a web-server. A PHP simply has a library what simplifies interaction with mysql program to a bunch of commands. So, PHP and MySQL are two different things, and SQL Injection applies to MySQL not to PHP. As someone who coded on PHP for 4+years, I think that language at its roots is a mess. Only way to make PHP something, is to rewrite everything from a scratch PROPERLY.
Don't most websites send text through some secondary language's, like JS or something, function to clean the input before sending it to the actual database?
The real question in that case is what constitutes "its own program".
You can run JavaScript via a browser, but the JavaScript code doesn't have to call browser specific (e.g. DOM) methods. You could (at least theoretically) write a JS code that works equally with a browser or with a server system (e.g. Node.js) or a build system (e.g. Visual Studio's ".w32" files). The language is all the same in all those environments. Only the non-core APIs of the runtime differ.
I am a professional database expert and I know that the language I am a specialist in, DB2, that 2 two things...
1 - This has been a well known security issue for many years, and any DBM or security expert would be fully aware of these specific issues
2 - Even if for whatever reason someone was able to input commands they shouldn't be allowed to input..
2A - There are restrictions on who is allowed to perform what operations and on which table(s)(and even which individual records). Even if someone was able to hack the command stream and input malicious commands, any reasonable database will have very easy to implement restrictions that make sure nobody could ever do or view anything they aren't supposed to, and CERTAINLY not do any sort of potentially seriously disruptful actions like deleting data or dropping all databases, lol. Just a very simple restriction on any potentially powerful commands to only the database admins would nullify any of these potential threats.
2B - Even IF something catastrophic was performed like "drop all databases" there are methods of restoring the database to previous states, not just by having BACKUPS saved somewhere, but by diagnostic logs that can be used to roll the environment back in time. I suppose it's possible to imagine a malicous attack that was smart enough and all-inclusive enough to delete all backups and relevant data needed to restore the environment, but just keeping a seperate copy of backups on a completely separate system would alleviate that possibility.
Love how this turned into a PHP promotional video with our host feeling the need to justify his usage of PHP! :D
Well, adding abstraction on top of another one to cover-up mess, starts to become clumsy. I've switched to C couple years ago, and I never regretted doing it since. With ~1 year of C experience, in couple weeks, I was able to write H T T P server from scratch using sockets and pthreads. In another couple weeks, I had dynamic pages and AJAX going. It looks daunting at first, but unless you try, you'll never know how handcuffed you were with PHP.
I quite like the moody lighting, gives it a nice atmosphere, Tom was a joy to listen to aswell.
This guy is one of the best on your channel! Get more videos from him!
bobby drop table students anyone
Sequel? I prefer squirrel injection. Sounds a lot cooler.
Who's here in 2022 when PHP has largely been replaced by Server side JS?
No, Jason's right.
The problem is "procedural instructions" is too vague a term to use to distinguish anything. It's what *everything* in computer programming boils down to. The "procedural" paradigm is a top-level category that includes several languages, including object-oriented ones.
Scripting is just an application, which "extension" is a fine synonym for. Any language can become a scripting language simply by being supported by another program, like browsers have done with JavaScript.
Yeah, I'd never heard about that site. I hit upon W3Schools a while back and was pretty horrified about what I saw being taught as gospel in their tutorials.
SEQUEL was different to SQL and used for ~12 years before the 1986 ANSI spec for SQL, in which the correct pronunciation is specified.
It may be that the pronunciation was only even defined to avoid copyright infringement, but since it's in the spec the pronunciation is just as well defined as the "SELECT" keyword, for example. Just as you can't swap "choose" or "find" or "get" for "select" in a query, there is a pronunciation that is defined as correct and other pronunciations are non-spec.
In php and all other modern programming languages the classes and functions to communicate with database are made so well I don't really have to worry about escaping the value. (pdo for example. no idea why would anyone still use mysql or mysqli even)
so is SQL injection similar to XSS or am i completely wrong here?
Tom, have you read "PHP: a fractal of bad design" on veekun? I think you may find the article very enlightening.
I'd love to see more about security from Tom, he just does a wonderful job explaining things.
SQL was designed under the name SEQUEL (Structured English QUEry Language), but Sequel just so happened to be a trademarked name of a UK company called Hawker Siddeley Aircraft so it had to be changed.
From that, we can assume both ways of saying are correct since Sequel was the name originally intended but "Es-Kyoo-El" is the amended one.
I'd like to hear more detail about other methods of injections. I've always been under the impression that properly escaping your inputs was enough to be safe...
I really like this guy, very enthusiastic, reminds me of my lecturer for databases
i am a greyhat hacker and always send this video to webmasters of vulnerable websites in the hope that they fix it
Of course, in some cases stored procedures/functions can be better, but that often ties you to a particular database/infrastructure stack.
It's a trade-off in your overall architecture. Lock yourself in with Stored Procedures, or be a little more flexible (useful in products you want to sell, especially to large businesses/enterprises).
Me and my friend always joked about naming a kid "DropTable" in our IS SQL intro course.
But I guess now I realized it should be something along the lines of: Frank";Droptable
The lighting in this video is really good.
And “proper handling” means query parameterization (prepared statements) - which was actually described in this video…
But you can’t do it with PHP’s mysql_*, hence the “easier in PHP”.
The recent ‘Super Mario World (1990)’ speedrun uses code injection in very fascinating ways that I don't understand. There is even a way to play PONG on the game using in-game sprites and complicated code injection.
One of additional benefits of database prepared statements is they usually offer a performance boost in returning the data. Not a huge amount mind you, but it adds up. If you need more complexity in database queries than prepared statements can do, than any web application should be using stored procedures. It is this specific point that royally pisses off most web programmers, because they need to learn the internals of something else, and their easy money job just became much more complicated.
On some websites it's intended for you to not be able to save some images or get a popup or have a chance to be redirected instead, when you click on a link. On some lower end websites you can go around all that by looking at the source code. Often there are links in the code that reveal the url of the images or you can figure out how to change the text of the link address (right click -> copy link address) to open it without extra popups.
Just because there is not a compiler from Javascript to machine code, doesn't mean it's not a programming language. The formal definition is more abstract and less practical. Also, there is a compiler language for PHP, take a look for HipHop, which allow you to compile from PHP -> C++ -> Code Machine (and don't tell me that C++ is in the middle, because every compiler makes a lot of “translations” before return the machine code, even the compilers of C++).
The solution is to convert "input" to a custom BASE64 encoding :)
then " in a string would be a different " than in the SQL script.
Just to make it completely clear, the correct pronunciation is "es queue el".
SEQUEL is a different thing. The pronunciation of SQL is defined in its spec and big DBMS (e.g. mysql and even microsoft sql) have also defined their pronunciations as "es queue el" at various stages.
I love your channel name and the videos are great! It really satisfies my love of technology, but makes me wanna learn more!
Where most people draw the distinction is a script is interpreted at run time, and a programming language is compiled into a binary before hand. There are many language that blur the line, but thats the general idea.
Good point. All JavaScript execution is done in a JavaScript interpreter, typically written in C. But if you're going to make that distinction, then you might as well say the most common language is x86 machine language.
Great info! SQL injection is a classic security flaw
Great vid !!
There is a lot of confusion about prepared statements at the moment.
It's more than string building for onwards processing.
The SQL statement is parsed and optimised for execution by the RDBMS.
The variable is inserted prior to execution by the optimiser.
In general, it's a good thing to prepare when you can. Just trust me.
Most DBAs will have a large list of their commonly executed statements.
It's safer and they gain some element of control over the SQL being executed.
You can easily protect a query like this "SELECT * FROM users WHERE user_id=" . $user_id (where user_id is an integer) by placing "(int)" in front of "$user_id" like "(int)$user_id". This casts the variable "user_id" as an integer. If someone types in something nefarious, it will just be converted into a harmless integer. Prepared statements may be safer but casting is better than nothing and is simple to do.
The one thing to mention: do not ever ever ever use PHP.
The CORRECT way to avoid this is don't create dynamic SQL in your application.. duh. Use stored procedures.
That's not the "only" reason for the bad rep. There are reasons the good programmers are leaving, and the situation is not improved simply by the existence of newer versions. New features don't fix the older ones, and PHP is notorious for adding features without proper design or consideration of pros and cons, by people who have a poor grasp on the features they are implementing. It's object oriented support is no exception.
SQL is an initialism, as it is properly pronounced "Ess Kew Ell". An acronym is an initalism that is pronounced as a word e.g. RADAR, SONAR, whereas SQL, FBI, PHP, etc. are initalisms as you pronounce the letters individually.
"...someone who uses Windows." The expression at 8:31 is priceless! :D
Does limiting the amount of access that the user has using sql permissions, say, in an oracle DB also solve the issue on its own? Say the user that logs in can only select data from the db, and only from certain tables and you deny them the 'drop', 'delete', 'alter' and other dangerous commands. Would that nullify the threat that injections pose? A hacker trying an injection would get back a 'you don't have permission to perform this operation' message, right? In the real world I'm assuming you use setting permissions in conjunction with the other techniques described in the video to make sure your data is 'safe,' not just relying on permissions alone.
You're right. In fact it's the same definition in Merriam Webster as it is in the Oxford Dictionary.
However, because it's American perhaps, It doesn't distinguish as much between similar words, in this case initialism or abbreviation. But in England, we're a bit more rigorous with our language. Check out the Oxford Dictionary definition.
I told countless times to the other developer at work to write all the SQL in procedures, and not inline in the application, but he did not listen to me. Now he works in another company, paid better than me. After a security check in my company, all my applications pass clean without errors, and all his applications have errors, and SQL injection problems. Now I have to fix all his applications, to transfer his inline SQL code to procedures. How fun is that !!!
You're right. For me, using PDO implicitly means "use it properly" i.e alway prepare the statements.
Thanks for pointing out.
A programming language is a formal language designed to communicate instructions to a machine, particularly a computer. Programming languages can be used to create programs that control the behavior of a machine and/or to express algorithms precisely. JavaScript is a programming language
The thing is, most people don't want to reinvent the wheel. If it works, it works. A whole lot of solutions out there are based on PHP, something other languages don't have. With PHP and a framework like Laravel you can get up and running extremely quickly and get a lot of support, documentation and extensions in that framework.
There are no real alternatives to that. If you don't want to build your own backend from scratch, PHP is the way to go for now.
These sorts of practices make me cringe inside. I salute you for your continued efforts.
Watching Video: Ok lets not be stupid.
After video: LET'S SEND SQL CODES ON EVERY SITE WE KNOW!!!
Luckily that's where frameworks come in. They clean up a lot of the mess by abstracting it away. All security features are handled in a consistent manner, all DB access is thoroughly cleaned, etc. Things are getting better though. PHP 5.5 just came out a few months ago with a bunch of really nice features. They are stepping up their game again.
This is one of those videos that have few comments but all from 6 years ago. And no replies, for some reason.
Last time, I just killed every user input that wasn't one of our 26 letters or 10 numbers. Stops SQL injection as well, though I think that would fall under "prepared statements".