Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I don't understand, I transferred my files to new hosting and now I can get SQL injection, even if I use mysql_escape_string or addslashes. Before that, I never could get an SQL injection. What's wrong? Please help, I am going crazy.
edit: There is no SQL injection if I use ", but it gives SQL injection, if I use '. My head will explode really soon...
I thinks that mysql_real_escape_string is the function you want to use to protect your application from SQL injection....
Also make sure magic quotes are off...
It is very hard to craft code that escapes/sanitizes inputs to a point where they would be safe to submit directly to a SQL database. What you really should do to make use of Parameterized Queries in your code for all interactions with your database. This allows your database to determine what should be considered "command" and what should be considered "data" so that injected SQL into the "data" will still be seen at data.
Read more at OWASP's excellent discussion about this topic.
You may have had insecure code at the old host, and you just didn't know about it until you put the code at the new host, and people started attacking it there for whatever reason.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 4 years ago.
Improve this question
I've heard a lot about SQL injection and also read a lot of good answers in other topics.
So I want to make sure I'm not vulnerable.
What if I encrypt all user input (wanted to do that anyway - using openssl) before inserting it into my mysql database?
Wouldn't it be an easy and safe way for a beginner to avoid sql injection?
I would not recommend encrypting everything just sensitive data. To prevent SQL Injection it is far more effective using proper request and input validation along with proper escape sequences and save yourself the headache of your application performance being hindered with every database transaction. Most of the time when you want to prevent prying eyes you use 1 way encryption on things such as a password. But if you are saving things such as credit cards and such its wise to follow the standardized security for credit card encryption. Encryption is good but over using it can cause far more problems than it saved you from. So think about what data is important and should be encrypted and then consider if it should be 1 way encryption or 2 way. But the most importantly is validation and never trusting the user input or the application request.
Please use
JSON Web Token
Write Stored Procedures in order tot encapsulate your TSQL query
SET DEFINE OFF will stop to prevent hackers use & for injection
Try to define parameters for queries like SqlCommand()
For know more about avoiding injection please read SQL Injection Prevention
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
I just wanted to ask a quick question about $_GET parameteres in php and the security of them. Although my get parameter is not visibily shown, it is in my url. I just wondered is there any extra steps I can take to make it even more secure?
I have a $_GET variable named page that determines what page their on, and its got a reqrite rule to check for the first word after slash
I know before you should use mysql_real_escape_string but that is now deprecated and will be removed in the future?? And updated way..
Example: http://example.com/pagehere
Would be passed as... http://example.com/index.php?page=pagehere
location / {
rewrite ^/(|/)$ /index.php?page=$1;
rewrite ^/([a-zA-Z0-9_-]+)(|/)$ /index.php?page=$1;
rewrite ^/(.*)\.htm$ /$1.php;
}
Just keep in mind that any incoming data from the user-end is not safe ever, so always take necessary steps to ensure it won't cause any problems in your system, as far as DB queries are concerned, ALWAYS use PHP PDO class to do your DB related tasks, using Prepared statements will nullify any SQL injection attacks, read more about prepared statements here - http://php.net/manual/en/pdo.prepared-statements.php
Using GET variables is not an issue if you handle it properly, when you read the data from $_GET you can use htmlspecialchars() to clean the data of any malicious code. Some useful information here - https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29
More information on how to use PDO to prevent SQL injection - How can I prevent SQL injection in PHP?
What is the parameter going to be used for? You should use filter input functions. If it's going to be used to query a databse, also use prepared statements. See http://php.net/manual/en/function.filter-input.php and http://php.net/manual/en/pdo.prepared-statements.php. Basically you need to sanitize the query string otherwise you leave the door open for possible exploits (server side inclusion attacks, sql injection, etc).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have a website where I need to fetch data from mysql and show them to user.
Every time user refreshes the page the mysql is going to connect, fetch som data, return it and the connection is closed (so user can be up-to-date).
There is a problem with it, because I tired to spam refreshes on my site and after 25.000 mysql connections in hour, my page is going to be down for an hour, because I have mysql_max_connection equal to 25.000 by my hosting provider.
I have only one account for MySQL there so I can't switch to any other account.
I was thinking about using the PDO::ATTR_PERSISTENT to make persistent connections, but there is no mysql_reset when the user comes back, so I think it's not a good idea to use it.
I wanted to ask if there is any way to prevent it within PDO or any other PHP/MySQL functions or how it's done by some commercial sites like facebook or so.
Thank you for your advise.
You can limit the usage per user per hour in MySQL:
LINK SECURITY MYSQL
However, most web apps use a single MySQL username for all application users. So this might just serve to throttle your whole website.
The addslashes function is not the right solution for preventing SQL injection. Every MySQL API includes a more appropriate escaping function, for example mysqli_real_escape_string() or PDO::quote().
But even better is to use prepared statements with query parameters instead of escaping and concatenating variables into SQL query strings.
Examples are easy to find if you examine other questions with the sql-injection tag. One of the best answers is in
How can I prevent SQL-injection in PHP?
Check and try these information. Good luck.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have to pass parameters throught my pages. For exemple ids of my database.
Is it a good idea to do so: www.example.com?id=10
Or have I to hash the parameter:
www.example.com?id=b1d5781111d84f7b3fe45a0852e59758cd7a87e5
It is really important to hash this one?
Thanks
Best regards
There is no need to hash Id's in query string. Yes it is visible to everyone but it's a common use. you should verify in your server side that this parameter cannot harm your application
How are you able to trace back the id for that specific hash? You will create a bottleneck if you need to get all your database id's and hash those to find your matching record.
Using id's in urls are commonly used, just dont put any sensitive data in your urls to protect your visitors (and yourself).
Also note that every visitor is evil. Always validate incomming data and do some proper error handling incase someone is messing around with the urls.
Ids are ok but I think the spirit of this question may be the result of a very real concern.
As others have said, you should expect evildoers to be using your site. Of particular concern with poorly design web applications, are SQL injection attacks. The ids themselves aren't an issue but if your backend is building a string of SQL, you could have issue. For example if your PHP code is taking that parameter and creating this SQL:
SQL = 'select * from product where id ='.$_GET['id']
Executing this SQL would be a major issue if someone changed their browser to call this page:
/product.php?id=1;DELETE FROM USERS;--
...you could end up with an empty database table.
Every language has its own way of protecting from this kind of thing, so make sure you are doing it the right way. For example, see this SO question How can I prevent SQL injection in PHP?
See https://www.owasp.org/index.php/SQL_Injection for more info
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am coding a social debating application, and I am worried about the security of prepared statements. Why does it bother me so much? Because social networks take massive amounts of user data and some may be malicious.
I just want to know if MySQLi's prepared statements feature enough to protect from the most common types of SQL injection. This has probably been asked before somewhere on the web, but, with the massive amount of outdated information in the net, it is very hard to know if there's been anything found about it.
I've heard various exploits on PDO, for example, yet some sites say there's no exploits. That's where confusion comes in. I understand that many exploits are found each day. But at least to protect from the most popular exploits.
And, if there are any additional methods of protecting SQL queries, please point them out in your answer.
Prepared statements are a good way to prevent MySQL injection. But what about XSS attacks? Those queries do not prevent users from submitting HTML or JavaScript code. If you don't take additional steps, they will simply alter your HTML code (if you output raw database results) and injected links to unwanted sites.
About Prepared Statements:
Prepared statements prevent any input from leaving its scope as a variable. That said every "ending quote" or such would be escaped and made harmless.
SQL injection is nearly impossible. But ... who said, that the native prepared statement is enough? if you trust your native prepare methods. OK. If not, try to break it yourself. Write test cases to proof, that most basic and maybe some more complex cases can not break your prepare statement methods.