I recently discovered that GET is a reserved word in SQLDeveloper,but I can't figure out what it's for. Tried oracle help center's list of reserved words but there's no mention of it.
In short: What is the use of GET in PLSQL?
It doesn't mean anything in PL/SQL, unless you have an object with that name. Or in SQL.
It's a SQL*Plus command:
GET [FILE] file_name[.ext] [LIST | NOLIST]
Loads an operating system file into the SQL buffer.
You can get a file into the buffer and edit it there before executing it, rather than just running it directly with start or #.
SQL Developer implements, or at least recognises or allows, most SQL*Plus statements, presumably for compatibility reasons (though some things don't work, such as set embed on).
It seems to silently ignore get.
It's in the documentation's keyword list, rather than the reserved words list. You can use it as an object name etc.; they recommend you don't, but as this is a client keyword rather than a SQL one it wouldn't be as noticeable. At least, if SQL Developer didn't highlight it as a keyword...
Related
I'm trying to work with some Visual FoxPro 9.0 code written years ago by programmers now long gone. There are several uses of ALLTRIM() that include a double-asterisk in front of the field name being passed, such as:
fred = ALLTRIM( **barney )
where Barney is a character field in a table. When I try running that line in a VFP session, it errors out with "Function is missing )". But I'm uncomfortable supporting code that I don't understand - what does the "**" do?
I've tried storing the field to a memvar, in case there's a SCATTER in the code that calls this, with no change in the resulting error. I've tried storing other data types (numeric and boolean) to the memvar, still no change. I've been programming in dBase, then FoxBase, then FoxPro, then VFP, for almost 35 years - and I don't remember ever coming across this before. And yet, the program runs without errors, I just don't understand what it is doing.
In case any of this matters, the code in question is stored in a memo field in a table, then invoked with an EXECSCRIPT() call. And some of the tables that the code is working with (but not the one containing the code) are SQL Server tables, accessed through cursor adapters - so "barney" in my example is very likely a field in a cursor adapter, not a .DBF.
I found my answer. Searching for asterisks in source code was useless, of course, because of comments. But I finally thought, after posting this question, of searching for the string with surrounding quotes, and found that, before the code I was looking at was called with EXECSCRIPT(), it was also run through STRTRAN(), which substituted "m." or "." or some other appropriate prefix for the "**" in the code.
So, the double asterisk was internal to the application, and meant nothing to VFP itself.
What is the practical difference between .pls and .sql file in oracle.
What are the restrictions on different types of statements in both?
I am given a project in unix(korn script) which uses both .sql and .pls files in different places. Trying to figure out which should be used where.
File suffixes are to a large extent just a matter of convention. We can use them to provide useful metadata to other developers.
So .pls indicates (we hope) that the file is a PL/SQL script, creating a PL/SQL package or stored procedure. In other shops we might see .pks and .pkb to indicate a package spec script and a package body script respectively. A file with a .tab or a .tbl extension indicates DDL to create a table. Because this is just a convention it requires discipline (or code reviews) to make sure we remain consistent.
The one difference is .sql. Although the convention is that it represents some SQL (a query, or perhaps DML or DDL) it has a special property in SQL*Plus. If we have a script called whatever.sql we can call it like this in SQL*Plus...
SQL> #whatever
... whereas if a script has any other extension we must include the extension in the call...
SQL> #whatever.pls
Other IDEs or others clients (e.g. build scripts) may use file extensions as a filtering mechanisms or for applying syntax highlighting, but their rules should always be controlled by preferences.
" What are the restrictions on different types of statements in both?"
To sum up, there are no restrictions. Some places I have worked used nothing but .sql files, Others had a complicated menagerie of scripts: .tbl, .idx, .vw, etc. Sociopaths can use just .txt for all their files: the database won't care. Provided it's valid Oracle syntax the code will run.
I have compiled a list of db object names, one name per line, in a text file. I want to know for each names, where it is being used. The target search is a group of folders containing sub-folders of source codes.
Before I give up looking for a tool to do this and start creating my own, perhaps you can help to point to me an existing one.
Ideally, it should be a Windows desktop application. I have not used grep before.
use grep (there are tons of port of this command to windows, search the web).
eventually, use AgentRansack.
See our Source Code Search Engine. It indexes a large code base according to the atoms (tokens) of the language(s) of interest, and then uses that index to quickly execute structured queries stated in terms of language elememnts. It is a kind of super-grep, but it isn't fooled by comments or string literals, and it automatically ignores whitespace. This means you get a lot fewer false positive hits than you get with grep.
If you had an identifier "foo", the following query would find all mentions:
I=foo
For C and Java, you can constrain the types of identifier accesses to Use, Read, Write or Defines.
D=bar*
would find only declarations of identifiers which started with the letters "bar".
You can write more complex queries using sequences of language tokens:
'int' I=*baz* '['
for C, would find declarations of any variable name that contained the letters "baz" and apparantly declared an array.
You can see the hits in a GUI, and one-click navigate to a source code view of any hit.
It is a Windows application. It handles a wide variety of languages: C#, C++, Java, ... and many more.
I had created an SSIS package to load my 500+ source code files that is distributed into some depth of folders belongs to several projects, into a table, with 1 row as 1 line from the files (total is 10K+ lines).
I then made a select statement against it, by cross-applying the table that keeps the list of 5K+ keywords of db objects, with the help of RegEx for MS-SQL, http://www.simple-talk.com/sql/t-sql-programming/clr-assembly-regex-functions-for-sql-server-by-example/. The query took almost 1.5 hr to complete.
I know it's a long winded, but this is exactly what I need. I thank you for your efforts in guiding me. I would be happy to explain the details further, should anyone gets interested using my method.
insert
dbo.DbObjectUsage
select
do.Id as DbObjectId,
fl.Id as FileLineId
from
dbo.FileLine as fl -- 10K+
cross apply
dbo.DbObject as do -- 5K+
where
dbo.RegExIsMatch('\b' + do.name + '\b', fl.Line, 0) != 0
I'm doing an audit of a system, which the developers insist is SQL injection proof. This they achieve by stripping out the single-quotes in the login form - but the code behind is not parameterized; it's still using literal SQL like so:
username = username.Replace("'", "");
var sql = "select * from user where username = '" + username + "'";
Is this really secure? Is there another way of inserting a single quote, perhaps by using an escape character? The DB in use is Oracle 10g.
Maybe you can also fail them because not using bind variables will have a very negative impact on performance.
A few tips:
1- It is not necessarily the ' character that can be used as a quote. Try this:
select q'#Oracle's quote operator#' from dual;
2- Another tip from "Innocent Code" book says: Don't massage invalid input to make it valid (by escaping or removing). Read the relevant section of the book for some very interesting examples. Summary of rules are here.
Have a look at the testing guide here: http://www.owasp.org/index.php/Main_Page That should give you more devious test scenarios, perhaps enough to prompt a reassessment of the SQL coding strategy :-)
No, it is not secure. SQL injection doesn't require a single-quote character to succeed. You can use AND, OR, JOIN, etc to make it happen. For example, suppose a web application having a URL like this: http://www.example.com/news.php?id=100.
You can do many things if the ID parameter is not properly validated. For example, if its type is not checked, you could simply use this: ?id=100 AND INSERT INTO NEWS (id, ...) VALUES (...). The same is valid for JOIN, etc. I won't teach how to explore it because not all readers have good intentions like you appear to have. So, for those planning to use a simple REPLACE, be aware that this WILL NOT prevent an attack.
So, no one can have a name like O'Brian in their system?
The single quote check won't help if the parameter is numeric - then 1; DROP TABLE user;-- would cause some trouble =)
I wonder how they handle dates...
If the mechanism for executing queries got smart like PHP, and limited queries to only ever run one query, then there shouldn't be an issue with injection attacks...
What is the client language ? That is, we'd have to be sure exactly what datatype of username is and what the Replace method does in regard to that datatype. Also how the actual concatenation works for that datatype. There may be some character set translation that would translate some quote-like character in UTF-8 to a "regular" quote.
For the very simple example you show it should just work, but the performance will be awful (as per Thilo's comment). You'd need to look at the options for cursor_sharing
For this SQL
select * from user where username = '[blah]'
As long as [blah] didn't include a single quote, it should be interpreted as single CHAR value. If the string was more than 4000 bytes, it would raise an error and I'd be interested to see how that was handled. Similarly an empty string or one consisting solely of single quotes. Control characters (end-of-file, for example) might also give it some issues but that might depend on whether they can be entered at the front-end.
For a username, it would be legitimate to limit the characterset to alphanumerics, and possibly a limited set of punctuation (dot and underscore perhaps). So if you did take a character filtering approach, I'd prefer to see a whitelist of acceptable characters rather than blacklisting single quotes, control characters etc.
In summary, as a general approach it is poor security, and negatively impacts performance. In particular cases, it might (probably?) won't expose any vulnerabilities. But you'd want to do a LOT of testing to be sure it doesn't.
What are the best ways (or at least most common ways) in ASP (VBScript) for input handling? My main concerns are HTML/JavaScript injections & SQL injections. Is there some equivalent to PHP's htmlspecialchars or addslashes, et cetera? Or do I have to do it manually with something like string replace functions?
The bottom line is this:
Always HTML-encode user input before you write it to your page. Server.HTMLEncode() does that for you.
Always use parameterized queries to interface with a database. The ÀDODB.Command and ADODB.CommandParameter objects are the right choice here.
Always use the URLScan utility and IIS lockdown on the IIS server that renders the page, unless they are version 6 and up, which do not require these tools anymore.
If you stick to points 1 and 2 slavishly, I can't think of much that can go wrong.
Most vulnerabilities come from not properly encoding user input or building SQL strings from it. If you for some reason come to the point where HTML-encoding user input stands in your way, you have found a design flaw in your application.
I would add to Tomalaks list one other point.
Avoid using concatenation of field values in SQL code. That is, in some cases a stored procedure may build some SQL in a string to subsequently execute. This is fine unless a textual field value is used as part of its construction.
A command parameter can protect SQL code designed to input a value from being hijacked into executing unwanted SQL but it allows such unwanted SQL to become data in the database. This is a first-level vunerability. A second-level injection vunerability exists if the field's value is then used in some SQL string concatenation inside a stored procedure.
Another consideration is that this is just minimal protection. All its doing is rendering attack attempts harmless. However in many cases it may be better to add to this a system which prevents such data entry altogther and/or alters admins to a potential injection attack.
This is where input validation becomes important. I don't know of any tools that do this for you but a few simple Regular Expressions might help. For example, "<\w+" would detect the attempt to include a HTML tag in the field.