I've a Postgresql database on my server and I would like to use it for a simple web-app on localhost. I've set the Database to allow my connections ecc.. In fact, my web-app can connect to the DB... But all the queries give no result in local. (That's funny because all the queries work great on the server.
Can you help me?
The first thing to do is this:
Login via psql, and run the following query (note the terminating semicolon):
SELECT version();
If that works, check to make sure you are terminating the queries with semicolons.
If that doesn't work, please copy/paste the complete output of psql (including prompts and greetings) here.
As a note, the psql prompt is very informative. The most important character for this purpose is the second from the right. That starts out as =, but changes to - if it is a continuation of a new line, ' if there is an unterminated single quote, " if there is an unterminated double quote, etc.
Related
Under the authorization of my friend, I am testing his website against potential vulnerabilities.
I was trying to find if I was able to inject a SQL query into a POST request parameter hi' or 1=1 --:
query=hi'%20or%201%3d1%20--
I found that the document prints out:
<div class="error">index job,query: syntax error, unexpected '-' near '-'</div>
while with ' or 0=0 -- I get:
<div class="error">index job,query: syntax error, unexpected '|' near ' | 0=0) --'</div>
does this mean that it's vulnerable to SQL Injection? If yes, how can I make it print server system data (like information, etc.)? By the way, if the string is correct it gets redirected to another webpage (I think that's why SQLMap tells me the parameter is not SQL-injectable).
EDIT: I can see the query works just if the URL gets redirected, but I won't see the query output. If the URL doesn't get redirected, I can see these SQL query errors. I'm trying to see how to get the output and do something more useful to attack the website, or even make it detectable from sqlmap.
The current command I'm using is sqlmap -r thework.txt -p query --dbs. thework.txt contains the full valid POST request.
SQL injection isn't only about malicious attacks that read data or change data on your site.
The majority of SQL injections are simply errors like the one you saw. They might not even be malicious. What if you have an SQL injection vulnerability that simply causes an error when someone wants to register their last name as "O'Reilly"? The user is well-intentioned, but your site breaks when they use their real name.
That's reason enough to detect and fix cases of SQL injection in your code.
You didn't post your code that builds the SQL query from this input, so what you have shown is only circumstantial evidence. But I do infer that you are copying a GET input into your SQL query without proper escaping or the preferred method, using a query parameter.
Wish I had 50 reps so I could put this in comments. But yes the site is most likely vulnerable. To be sure ask your friend to allow you to run an initial exploit.
sqlmap.py -u < Target Address> --dbs
If you successfully pull up the data base you have found the vulnerability or at least have confirmed there is a vulnerability.
I'm doing some webpentesting exercises and there is this one task saying that I need to make a new account with this name and this password by using SQL injection. On the web page there is a text input username and another text input 'password'. I can enter whatever characters I want inside the username text-input but inside the password text input I need to type a specific injection.
I know I need to inject insert query but the thing is I don't know the table name. In order to insert a new user I need to know the table name so I'm wondering how can I make the web showing me an error with tablename revealed.
The error showing should be like:
Unexpected end of command in statement [SELECT * FROM (tablename) WHERE...]
I tried to enter with just one character (maybe >1 chars are required) inside the password field to make the error show or even delete the parameter text input password. But it just won't show the SQL syntax error.
So the question is: How can I make use of the exploit to make the web page view the SQL syntax error with table name revealed?
And why doesn't injection work on username field but it does on password field?
The first thing is understand the difference between "application" errors (for example, "the user doesn't exist") and execution errors, in which the application fails itself, like the "Unexpected end of command" you mention. The first case is not usually a problem from the security point of view (unless the application is very badly programmed), the second one is what could allow hacking.
A well programmed web application should ideally only have application errors, but the more realistic approach is cope with unexpected execution errors in way that don't make it vulnerable. Also, application should process any user input in a way that don't cause an execution error.
It seems that they are teaching you the most flagrant case that allows SQL injection, apps than don't do any processing to user input (so it's very easy put text in an input field that cause an execution error), and that don't cope with execution errors (in this case, showing the internal execution message to the user).
A common mistake in web applications is constructing the SQL query with string concatenation, so the simplest way of make it fail is using the string delimiter (') in a field, causing the string value to end prematurely. In an sloppy web app it would cause an execution error that shows the full error message, usually including the table name.
From there you craft a SQL query in the input field that insert the user in the table, you could find examples online (note that you need at least basic knowledge on SQL and PHP (or ASP, Java, etc.), in order to do SQL injection, since you need to know how the database access works in order to make it fail).
Finally, SQL injection could work in any input field that is not properly processed, but it depends on how the application is programmed. I suppose that both fields would work but it will be easy do that with the password field because probably is the last one in the SQL query.
I am attempting to tune our oracle database that has been running a little slowly lately.
I have generated a SQL trace file, and can run the basic TKPROF from the command prompt, and generate the appropriate output file.
tkprof.exe source.trc output.txt
I would very much like to see the execution plan as well since there are a good number of indexes that should be used with this database. To do this, I am trying to run this:
tkprof.exe source.trc output.txt EXPLAIN=mbw/password
The problem is, the username which every application uses to connect with is lowercase (mbw for this example, and I have to leave it this way). So whenever I wish to look at data, I have to put quotes around the user like this:
SELECT * FROM "mbw".TABLE1
Unfortunately, I can never seem to get TKPROF to connect as "mbw"/password, it is always as mbw/password, which will never work. (I can see what TKPROF is attempting to connect with in the output.txt file)
I have tried a bunch of permutations on the command line, and just can't seem to make it happen. I've tried things like:
... EXPLAIN="mbw"/password
... EXPLAIN=""mbw""/password
... EXPLAIN="""mbw"""/password
... EXPLAIN=^"mbw^"/password
Does anyone have any ideas on how to properly structure the TKPROF command so I can connect as a user with lowercase letters?
I fully apologize for my lack of good oracle and sql skills, I have been rather unexpectedly thrown into this particular job and am trying to learn as fast as I can.
Issue with Delphi legacy code. Added one line of code to correct one error and created a new error.
New error is causing the same executable to yield different results on different servers(switched the pointer from dev to prod environment on the executable).
code:
sEscapedString:=stringreplace(sStringIn,'[','''+char(27)+''[',[rfReplaceAll]);
sEscapedString:=stringreplace(sEscapedString,']','''+char(27)+'']',[rfReplaceAll]);
sEscapedString:=stringreplace(sEscapedString,'''','''''',[rfReplaceAll]);// this line created new
bug
result:=' like ''' + Trim(sEscapedString) + '%'''+' escape char(27) ';
When running the code against dev this query finds objects with the characters '[' and ']' in it
Against prod the query does not find those items:
The first thing I checked was the data: Exactly identical in both cases
The second thing I checked was SQL server versions (11.0.3128 on BOTH servers)
The third thing I am checking is settings on those servers:
DBCC USEROPTIONS; -- same on both
SELECT name, collation_Name FROM sys.databases -- same on both
select ##OPTIONS -- same on both.
Quoted identifiers are 'ON' for both servers
It comes down to the fact that I know one server is treating the escape character (chr(27)) differently than the other but I do knot know why.
Does anyone have a theory(or answer) as to why the 2 similar servers are treating the escape characters differently?
The goal here is getting the prod server to return values with '[' and ']', as setting up my system to work with the legacy code will take a LOT of additional time. I do have a fix for the code
sEscapedString:=stringreplace(sStringIn,'[','[[]',[rfReplaceAll]);
But the faster option would seem to be getting the server to read the values the same.
Update: We found the root cause of the difference and it was more mundane than what we expected, turns out the query we were running was actually executed twice. The second execution was missing the key piece on the production server.
The issue was resolved by moving the new line of code so that it executed first rather than last.
I would first try to find out if this SQL only causes different behaviour when it is sent from the application: by sending the SQL from an interactive SQL client tool to both servers.
To make sure that the manually tested SQL is exactly the same as in the application, I would try to log or capture the exact SQL as sent from the application as a text file and then paste its content to the SQL client tool.
If the server is the culprit, then using the SQL from a different client tool should cause the same difference with the two servers. If the client tool shows the same (correct) result on both servers, then something is going on in the Delphi application.
p.s. upvoted, it is an interesting phenomenon
I am wondering if anyone can explain why I get different results for the same query string between using the ExecuteSQL function in FM versus querying the database through a database browser (I'm using DBVisualizer).
Specifically, if I run
SELECT COUNT(DISTINCT IMV_ItemID) FROM IMV
in DBVis, I get 2802. In FileMaker, if I evaluate the expression
ExecuteSQL ( "SELECT COUNT(DISTINCT IMV_ItemID) FROM IMV"; ""; "")
then I get 2898. This makes me distrust the ExecuteSQL function. Inside of FM, the IMV table is an ODBC shadow, connected to the central MSSQL database. In DBVis, the application connects via JDBC. However, I don't think that should make any difference.
Any ideas why I get a different count for each method?
Actually, it turns out that when FM executes the SQL, it factors in whitespace, whereas DBVisualizer (not sure about other database browser apps, but I would assume it's the same) do not. Also, since the TRIM() function isn't supported by MSSQL (from what I've seen, at least) it is necessary to make the query inside of the ExecuteSQL statement something like:
SELECT COUNT(DISTINCT(LTRIM(RTRIM(IMV_ItemID)))) FROM IMV
Weird, but it works!
FM keeps a cache of the shadow table's records (for internal field-id-mapping). I'm not sure if the ExecuteSQL() function causes a re-creation of the cache. In other words: maybe the ESS shadow table is out of sync. Try to delete the cache by closing and restarting the FM client or perform a native find first.
You can also try a re-connect to the database server via the Open File script step.
HTH