I'm new to MySQL, and am wondering: Is it possible to make a table check attempted inserts against some sort of pattern match, and reject any inserts that fail to match the pattern, or must this checking all be done PHP / what-ever-server-side-language side?
I'm thinking specifically about confining an email column in a user table to only be able to contain email addresses using some sort of regex-like pattern matching.
Because you can do something with a DBMS stored procedure doesn't make it a good idea. I strongly suggest you do this kind of validation in PHP rather than in the DBMS.
PHP's install kit contains a validator for email. See here: http://php.net/manual/en/filter.filters.validate.php
If you do this in your DBMS you have to reinvent the flat tire, er, wheel.
Although an answer was already accepted, I believe there are use cases for doing validation on the db side.
It's an extra layer of security. While there is such a thing as overkill I think the case could be made that no matter how well you validate on the application side and use parameter binding with PDO there is always a possibility someone figures out a way to get around it.
If the same data might be used by more than one application, it enforces rules in case a developer for a different app fails to validate correctly.
Here is a example of validation using triggers in mysql. http://cvuorinen.net/2013/05/validating-data-with-triggers-in-mysql/
And here you can see how you might replace the code in those IF statements with regex. regular expressions inside a SQL IF statement
I haven't tried it so don't know if it works but there is a link to the mysql docs on regex.
http://dev.mysql.com/doc/refman/5.1/en/regexp.html
And of course you should always validate on the application side too.
Related
I realized an invoicing application in J2EE(jsp,servlet), after having finished my program and tests, I noticed the following error:
my sql server table FACTURE contains:
Price NUMERIC (6,2)
the user enters 333.33 is good but WHENE HE enters
333333 is the error.
is there any other type in sql server that allows me to enter data in this way without errors MOSTLY I WANT DISPLAY WITH DECIMAL,I tested type float but it doesn't allow me to display zeros at the end.
You need to format it as a string. Look into NumberFormat or if you're working with some web framework there is more than likely some framework specific way of doing it, such as <fmt:formatNumber/> tag for JSPs or <f:convertNumber/> for JSF.
Update
It seems I misread the question, my appology. You're asking about validating data. In that case you either need to write the validation code yourself and based on the validation logic determine whether to persist the data or display an error message. Again, frameworks will have facilities that will make this easier. Primefaces has a neat one <p:inputMask/>. For JSF, you'd use a combination of a converter and validators, see this for an extensive discussion. I'm sure other web frameworks have similar facilities.
Store it as a float in the database and then use a NumberFormat.getCurrencyInstance().format() when displaying the value.
A normal UNION based SQL Injection can be blocked using the WAF, which filter keywords like UNION, SELECT. But I've that it can be bypassed by the inline comment statements of SQL such as /*!UNION*/ and /*!SELECT*/
Comment statements are meant for only reading purpose, right? If so, how a SQL server reads the injection query inside the comments and executes it?
Filtering keywords with a WAF is pointless. There is no way it could possibly succeed. Take a look at this list of ways to bypass it: http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/ (And I found that link in just a few seconds with google.)
If the code was written correctly, it would not be necessary.
As for your question the /*! syntax of MySQL is for MySQL specific commands. It's intended for you to be able to write portable SQL (that can run on any database) and yet still be able to send MySQL special commands.
SQL injection should not be an issue at all if you're using a database driver that supports placeholders for data. What you'd be trying to do with an after-the-fact detection is futile, like trying to eradicate a roach infestation with a ratty fly-swatter. You can't possibly get them all.
The best practice is to ensure it's impossible to inject hostile data into your queries in the first place. There are many examples available on Booby Tables that illustrate how to do this properly.
Commenting out partial query by not closing them can be used for bypassing blacklisting, removing spaces, obfuscating and determining database versions.
The one that you've mentioned is a special comment syntax for MySQL. If you put a code into this comments it's going to execute in MySQL only. Also you can use this to execute some code only if the server is higher than supplied version. For example:
Classical Inline Comment SQL Injection Attack Samples
ID: /*!32302 10*/
ID: 10
You will get the same response if MySQL version is higher than 3.23.02
I want to prompt the user to enter a database name and warn him if it is invalid.
Is there an easier way than actually trying to create the database and checking the result?
No biggy, I'm just curious. PHP and MySql, but I need it to be ODBC compliant.
You should have your PHP script validate the name before submitting it, and have it catch any error that comes back from MySQL when trying to create it.
The PHP could validate the name against a regular expression, for example. Maybe you want to only permit alphabetical characters.
In fact, I strongly recommend only accepting alphabetical characters, and validating this before ever sending anything to a database command... no sense giving anyone any chance to submit values that could end up causing SQL injection, in the context of a user with the ability to create databases.
But I would also ask; Do you really need to allow users to define their own database names? It might seem 'nice' to enable it, but is there any real benefit over generating a semi-random or incrementing name to users, eliminating any need to validate their input in this particular case?
I'd love to do this:
UPDATE table SET blobCol = HTTPGET(urlCol) WHERE whatever LIMIT n;
Is there code available to do this? I known this should be possible as the MySQL Docs include an example of adding a function that does a DNS lookup.
MySQL / windows / Preferably without having to compile stuff, but I can.
(If you haven't heard of anything like this but you would expect that you would have if it did exist, A "proly not" would be nice.)
EDIT: I known this would open a whole can-o-worms re security, however in my cases, the only access to the DB is via the mysql console app. Its is not a world accessible system. It is not a web back end. It is only a local data logging system
No, thank goodness — it would be a security horror. Every SQL injection hole in an application could be leveraged to start spamming connections to attack other sites.
You could, I suppose, write it in C and compile it as a UDF. But I don't think it really gets you anything in comparison to just SELECTing in your application layer and looping over the results doing HTTP GETs and UPDATEing. If we're talking about making HTTP connections, the extra efficiency of doing it in the database layer will be completely dwarfed by the network delays anyway.
I don't know of any function like that as part of MySQL.
Are you just trying to retreive HTML data from many URLs?
An alternative solution might be to use Google spreadsheet's importHtml function.
Google Spreadsheets Lets You Import Online Data
Proly not. Best practises in a web-enviroment is to have database-servers isolated from the outside, both ways, meaning that the db-server wouldn't be allowed to fetch stuff from the internet.
Proly not.
If you're absolutely determined to get web content from within an SQL environ, there are as far as I know two possibilities:
Write a custom MySQL UDF in C (as bobince mentioned). The could potentially be a huge job, depending on your experience of C, how much security you want, how complete you want the UDF to be: eg. Just GET requests? How about POST? HEAD? etc.
Use a different database which can do this. If you're happy with SQL you could probably do this with PostgreSQL and one of the snap-in languages such as Python or PHP.
If you're not too fussed about sticking with SQL you could use something like eXist. You can do this type of thing relatively easily with XQuery, and would benefit from being able to easily modify the results to fit your schema (rather than just lumping it into a blob field) or store the page "as is" as an xhtml doc in the DB.
Then you can run queries very quickly across all documents to, for instance, get all the links or quotes or whatever. You could even apply XSL to such a result with very little extra work. Great if you're storing the pages for reference and want to adapt the results into a personal "intranet"-style app.
Also since eXist is document-centric it has lots of great methods for fuzzy-text searching, near-word searching, and has a great full-text index (much better than MySQL's). Perfect if you're after doing some data-mining on the content, eg: find me all documents where a word like "burger" within 50 words of "hotdog" where the word isn't in a UL list. Try doing that native in MySQL!
As an aside, and with no malice intended; I often wonder why eXist is over-looked when people build CMSs. Its a database that can store content in its native format (XML, or its subset (x)HTML), query it with ease in its native format, and can translate it from its native format with a powerful templating language which looks and acts like its native format. Sometimes SQL is just plain wrong for the job!
Sorry. Didn't mean to waffle! :-$
I was having a discussion with coworkers. We have to implement some security standards. We know not to store 'sensitive, addresses, date of birth' information in hidden fields but is it OK to use hidden fields for your application, in general.
For example:
action=goback
It seems like it would be safer to use hidden fields for that kind of information as opposed to adding it in the query string. It is one less piece of information that a hacker could use against your application.
A hacker can access hidden fields just as easily as querystring values by using an intercepting proxy (or any number of tools).
I dont think there is anything wrong with using hidden fields as long as they aren't used for anything sensitive and you validate them like you would any other value from the client.
Making a field "hidden" has pretty much nothing to do with security, and should be considered a UI decision. Any "hacker" will read your HTML source anyway.
Better to either not show sensitive information at all, or, if you must, to use SSL (to prevent data interception by network intermediaries) and some combination of login challenges (to prevent unauthorized access).
It's only a security hole if you're exposing information that wouldn't be otherwise available to the end user and/or aren't validating it on return.
I'd look instead to storing said information in a server side session variable instead...
Storing your data in a hidden field is, from a security standpoint, exactly the same as storing it in the query string. In fact, if your form uses the GET action, it ends up int he query string anyway.
Hidden fields are completely unrelated to security in any way; they are simply a method by which data can be stored in a form without forcing the user to see it. They do not provide a way of preventing the user from seeing it.
Hidden fields are not always an issue, but they should always ring alarm bells as they have two potential problems:
1) If the data is sensitive, it exposes it to the client (e.g. using a proxy, or simply view source - and it is pointless to try and prevent this programmatically)
2) If the data is interpreted by the server, a knowledgeable user can change it. To take a silly example, if the hidden field contains the user's bank balance, they could use a proxy or some non standard client to make the server think their bank balance is anything they choose.
The second one is a big source of vulnerabilities in webapps. Data associated with the session should be held server side, unless you have a means of validating it on the server (for example if the field is signed or encrypted by the server).
Provided you are sure you're not falling into either of these traps, they can be OK to use. As a rule of thumb, I would not use hidden fields except for data you would be happy to see in the query string, or if javascript needs them for processing. In the latter case, you still need to make sure the server is validating though, don't assume the client will run your javascript.
Consider encrypting the name and value of your hidden field for the purpose of tamper checking since hackers can still get hold of your hidden fields and manipulate them the way they wanted to.
As other people have mentioned both the query string and hidden fields are essentially public data, viewable by the user.
One thing to keep in mind if you place data on the querystring is that people pass urls around, and because of this should never contain any information specific to the current user.
It is also probably a good idea not to include state information in the url, if that state can not be entered directly. Or at least you would need to handle invalid state information in the querystring.
I would say that this is no more or less safe than placing the item in the query string. After all, one could always view source on the site (and there isn't any way to prevent that, since one could always programmatically download the source).
A better solution here would be to encrypt the names of the fields and the values with a key that is generated on the server, and only the server. Unless the server was hacked, the client wouldn't have any clue what the name of the value is, or its value.
Of course, since this is coming from the client, you still have to check the validity of the data coming back, don't just take for granted that it hasn't been altered in a manner that you didn't dictate.
To that end, you will want to use hashing to make sure that the value hasn't been tampered.
In general don't use hidden form fields for sensitive data. Only for static non sensitive POST data that you realise is not safe to handle "as its recieved". The only time i use them is to store Session Tokens as they're rendered and checked upon recieving the POST. To prevent CSRF attacks or atleast make them a great deal harder.
In addition to all the other useful advice by other posters, I'd also add that hidden fields make your app no less vulnerable to SQL injection attacks as url query string values do. As always, sanitise your input.