We have namespaces with periods in their names. E.g. budget.region1.
How can we use aql to query these namespaces?
aql uses periods to delimit namespace from set, and appears to be confused by the periods in our namespace name:
aql> select * from budget.region1
Error: (20) AEROSPIKE_ERR_NAMESPACE_NOT_FOUND
We have tried single and double quotes around the namespace name, backslash-escaping the period, etc., with no luck.
Is aql usable with our namespaces?
(Answers that ask us to use client libraries (Python, Go, etc.) are not useful. We're asking about the command line client. Since ascli is deprecated/gone, we're forced to use aql.)
Thanks!
Unfortunately, aql does not parse namespaces containing periods. I recommend logging a bug with Aerospike.
Related
I have the following code running for logging in.
M_INVALID_PASSWORD_OR_USERNAME_2 SELECT `s1_members`.* FROM `s1_members`
WHERE (`password` LIKE '5bd7002ef05124e82000bb83d83455ec8c50a1e8') AND
(email LIKE 'test#tefrfrfwfe.frrfr' OR phone LIKE 'test#tefrfrfwfe.frrfr')"
I know my email/phone seem to be vulnerable, but I am escaping singled quotes by adding two backlashes (\) before each single quote. The double quotes get escaped by adding three backlashes beforehead (\). I also escape backslash by adding three more backslashes after (\).
I am still a learning in this field, so want to know in what ways/payloads then can an attacker inject an SQL injection? If there are payloads that will be executable here, then how do I protect myself?
I have tried different kinds of SQL injections I could find on Internet and seems that my special character escaping is working fine. I know it's not ideal though, so want to know what type of payloads of SQL injection can be successfully executed in my code.
You should use prepared statements (aka parameterized queries). When using prepared statements the parameters are never interpreted as SQL, they're simply processed by the database as data.
The escaping technique you're using, even if it works, is fragile. It is dependent on the client language, how the string is composed on the client, and which database you're using.
A couple of things that could go wrong:
The string on the client could have a fixed length - the encoding mechanism can be manipulated by the hacker to overrun that length. That can be used to truncate off key parts of the query or create buffer overflows.
The slashes may be interpreted by the client language as well, switching the client context might change the number of slashes required.
The database might change - either because the code is used with a different database or the behavior changes on upgrade. As mentioned by Jeroen in the comments, databases all handle encoding differently.
I'm trying to import a CREATE TABLE statement in NexusDB.
The table name contains some german umlauts and so do some field names but I receive an error that there were some invalid characters in my statement (obviously the umlauts...).
My question is now: can somebody give a solution or any ideas to solve my problem?
It's not so easy to just change the umlauts into equivalent terms like ä -> ae or ö -> oe since our application has fixed table names every customer uses currently.
It is not a good idea to use characters outside what is normally permitted in the SQL standard. This will bite you not only in NexusDB, but in many other databases as well. Take special note that there is a good chance you will also run into problems when you want to access data via ODBC etc, as other environments may also have similar standard restrictions. My strong recommendation would be to avoid use of characters outside the SQL naming standard for tables, no matter which database is used.
However... having said all that, given that NexusDB is one of the most flexible database systems for the programmer (it comes with full source), there is already a solution. If you add an "extendedliterals" define to your database server project, then a larger array of characters are considered valid. For the exact change this enables, see the nxcValidIdentChars constant in the nxllConst.pas unit. The constant may also be changed if required.
I try to create a phonebook with OpenLDAP 2.4.31 with the standard schemas.
Inserting a number containing a hash (#) or asterisk (*) won't work and return me a syntax error.
RFCs tell me that a number is the following: Printable string (alphabetic, digits, ', (, ), +, ,, -, ., /, :, ?, and space) and "
How can I edit the schema to support # and * characters?
We are having the same exact issue! Mobile networks offer a variety of services and information accessed using numbers that include either pound (hash) or star. Its a perfectly valid question for perfectly normal use of a phone number field.
Having a very casual look at RFC 4517, I see that it's really true! The LDAP RFC offers only a very limited selection of basic syntax types, and telephoneNumber maps to PrintableString. Probably a case of the RFCWG more interested in their RFC for its own sake, than the practical application thereof. I mean, which would be more useful in a phone number field - '?' or '#'..
As was already alluded, hacking cosine.schema can lead to even larger problems and is not upgrade-safe. FYI there are a few LDAP servers out there, many a bit more flexible about the RFC implementation. Have a look at OpenDJ:
https://forgerock.org/opendj/
Any server-side 'fix' in this case will likely no longer be strictly RFC compliant, which runs the risk of your original syntax issues revisiting you, if you ever need to exchange LDIF with other LDAP systems. But IMHO changing the client mapping to another unrelated field type could hardly be called 'better', especially from an onlooker's perspective. So either get another LDAP server which is more forgiving or change the field mapping on the client - either way presents risks and should be understood as a limitation of RFC 4517.
You would have to change the OID in the telephoneNumber schema entry to refer to a more general attribute syntax OID as per the RFCs. Not a good idea. You would be better off using a different attribute.
Once I had spent hours in debugging a simple SQL query using mysql_query() in PHP/MySQL only to realise that I had missed bactick around the table name. From then I had been always using it around table names.
But when I used the same in SQLite/C++, the symbol is not even recognized. It's confusing, whether to use this or not? What does standard say about usage of it?
Also, it would be helpful if anyone could tell me when to use quotes and when not. I mean around values and field names.
The SQL standard (current version is ISO/IEC 9075:2011, in multiple parts) says nothing about the 'back-tick' or 'back-quote' symbol (Unicode U+0060 or GRAVE ACCENT); it doesn't recognize it as a character with special meaning that can appear in SQL.
The Standard SQL mechanism for quoting identifiers is with delimited identifiers enclosed in double quotes:
SELECT "select" FROM "from" WHERE "where" = "group by";
In MySQL, that might be written:
SELECT `select` FROM `from` WHERE `where` = `group by`;
In MS SQL Server, that might be written:
SELECT [select] FROM [from] WHERE [where] = [group by];
The trouble with the SQL Standard notation is that C programmers are used to enclosing strings in double quotes, so most DBMS use double quotes as an alternative to the single quotes recognized by the standard. But that then leaves you with a problem when you want to enclose identifiers.
Microsoft took one approach; MySQL took another; Informix allows interchangeable use of single and double quotes, but if you want delimited identifiers, you set an environment variable and then you have to follow the standard (single quotes for strings, double quotes for identifiers); DB2 only follows the standard, AFAIK; SQLite appears to follow the standard; Oracle also appears to follow the standard; Sybase appears to allow either double quotes (standard) or square brackets (as with MS SQL Server — which means SQL Server might allow double quotes too). This page (link AWOL since 2013 — now available in The Wayback Machine) documents documented all these servers (and was helpful filling out the gaps in my knowledge) and notes whether the strings inside delimited identifiers are case-sensitive or not.
As to when to use a quoting mechanism around identifiers, my attitude is 'never'. Well, not quite never, but only when absolutely forced into doing so.
Note that delimited identifiers are case-sensitive; that is, "from" and "FROM" refer to different columns (in most DBMS — see URL above). Most of SQL is not case-sensitive; it is a nuisance to know which case to use. (The SQL Standard has a mainframe orientation — it expects names to be converted to upper-case; most DBMS convert names to lower-case, though.)
In general, you must delimit identifiers which are keywords to the version of SQL you are using. That means most of the keywords in Standard SQL, plus any extras that are part of the particular implementation(s) that you are using.
One continuing source of trouble is when you upgrade the server, where a column name that was not a keyword in release N becomes a keyword in release N+1. Existing SQL that worked before the upgrade stops working afterwards. Then, at least as a short-term measure, you may be forced into quoting the name. But in the ordinary course of events, you should aim to avoid needing to quote identifiers.
Of course, my attitude is coloured by the fact that Informix (which is what I work with mostly) accepts this SQL verbatim, whereas most DBMS would choke on it:
CREATE TABLE TABLE
(
DATE INTEGER NOT NULL,
NULL FLOAT NOT NULL,
FLOAT INTEGER NOT NULL,
NOT DATE NOT NULL,
INTEGER FLOAT NOT NULL
);
Of course, the person who produces such a ridiculous table for anything other than demonstration purposes should be hung, drawn, quartered and then the residue should be made to fix the mess they've created. But, within some limits which customers routinely manage to hit, keywords can be used as identifiers in many contexts. That is, of itself, a useful form of future-proofing. If a word becomes a keyword, there's a moderate chance that the existing code will continue to work unaffected by the change. However, the mechanism is not perfect; you can't create a table with a column called PRIMARY, but you can alter a table to add such a column. There is a reason for the idiosyncrasy, but it is hard to explain.
Trailing underscore
You said:
it would be helpful if anyone could tell me when to use quotes and when not
Years ago I surveyed several relational database products looking for commands, keywords, and reserved words. Shockingly, I found over a thousand distinct words.
Many of them were surprisingly counter-intuitive as a "database word". So I feared there was no simple way to avoid unintentional collisions with reserved words while naming my tables, columns, and such.
Then I found this tip some where on the internets:
Use a trailing underscore in all your SQL naming.
Turns out the SQL specification makes an explicit promise to never use a trailing underscore in any SQL-related names.
Being copyright-protected, I cannot quote the SQL spec directly. But section 5.2.11 <token> and <separator> from a supposed-draft of ISO/IEC 9075:1992, Database Language SQL (SQL-92) says (in my own re-wording):
In the current and future versions of the SQL spec, no keyword will end with an underscore
➥ Though oddly dropped into the SQL spec without discussion, that simple statement to me screams out “Name your stuff with a trailing underscore to avoid all naming collisions”.
Instead of:
person
name
address
…use:
person_
name_
address_
Since adopting this practice, I have found a nice side-effect. In our apps we generally have classes and variables with the same names as the database objects (tables, columns, etc.). So an inherent ambiguity arises as to when referring to the database object versus when referring to the app state (classes, vars). Now the context is clear: When seeing a trailing underscore on a name, the database is specifically indicated. No underscore means the app programming (Java, etc.).
Further tip on SQL naming: For maximum portability, use all-lowercase with underscore between words, as well as the trailing underscore. While the SQL spec requires (not suggests) an implementation to store identifiers in all uppercase while accepting other casing, most/all products ignore this requirement. So after much reading and experimenting, I learned the all-lowercase with underscores will be most portable.
If using all-lowercase, underscores between words, plus a trailing underscore, you may never need to care about enquoting with single-quotes, double-quotes, back-ticks, or brackets.
Brief Description of the app:
I have written a Delphi application that allows a user to run a query over either a MySQL database, or a DB2 database. The application uses a TADOQuery component to run the query.
The application uses a simple interface to build the query string, allowing users with no knowledge of SQL to build queries. At no point does the user see any SQL - everything is in plain English so that even non-technical users can understand what they are doing.
The applicatione examines the parameters that the user entered using the query building interface and builds the SQL statement in the background, submitting it without the user actually seeing the SQL itself.
Problem:
Some of the queries use substrings to retrieve data from within certain fields. When I use the SUBSTR statement, I'm not adding spaces after the commas within the SUBSTR statement. For example, SUBSTR(field,1,10).
This is fine most of the time, but when the locale on the PC is set to a different locale from English (e.g. Dutch, changed via the Regional Settings applet in the Windows Control Panel), the SUBSTR statement in this form fails when running over a DB2 database (it seems fine over MySQL).
In order to get the SUBSTR to execute properly in that particular locale, I need to add spaces after the commas. For example, SUBSTR(field, 1, 10).
Searching for the correct syntax for the SUBSTR statement shows examples both with and without commas, although obviously I've found problems when I've not included commas, so I'd be inclined to go with the version with spaces. However, what I want to know is whether or not this is the definitive syntax, whether or not I'll get any problems using SUBSTR in this way, and as a bonus, why I get the error when I don't use spaces after the commas in the first place.
The proper way is with or without space. Spaces are optional and not parsed, you can even have 10 spaces after comma and 3 before if you like (just arbitrary numbers).
The reason why SUBSTR(field,1,10) doesn't work in some locales is because of the part I highlighted. In European countries, the decimal sign is comma, not period. By putting a space and making it SUBSTR(field, 1, 10), the 1, 10 is very clearly split into two parameters so there is no longer any confusion.