I have API like
"/getXXXX?ABC=X7TRYUV&Ab_DEF=true&Ab_XYZ=true&Ab_ExZ=ZXTY"
How can I check the vulnerability of the request parameters?
What type of strings I can pass?
I ran the API in Wapiti and SQLMAP tool but found no issue.
manually i have tested it with by manipulating "Ab_ExZ=ZXTY" to 'CHR(91%2d1)'XTY
and It filter out the result as correct parameter where it should not filter out.
Thanks,
Bibek
Unfortunately the answer to your question is it depends. There is a lot of useful information about injection style attacks available from OWASP. The exact strings that you should use depend on the underlying technology of your solution and the characters e.g. terminating characters that are significant at each stage the data is processed.
A starting point for testing injection is to try to terminate the statement / command. For example in Oracle PL/SQL the characters '; will work by the quote closing the string entry and the semi colon terminating the command. If the query is prone to injection attacks this will most likely give you an error from the database for a malformed query.
Obviously other databases will have slightly different syntax. Also worth considering is the underlying OS. If the input to the API is ending up being executed at the command line, is it Windows or Linux based? This will change the syntax that you want to try.
Finally, if data is being stored where is it then rendered? If it becomes rendered in a Web UI you can try inputing <b> obviously if your API allows this to be stored and then displayed to the user without being escaped you will see text in bold. This would indicate a second order injection attack. (The actual risk is when the data is retrieved rather than being sent).
I strongly recommend taking a look at the injection information available on OWASP's site. Including the WebGoat examples where you can have a go at trying injection style testing against a deliberately vulnerable web site. The principles will translate nicely to the API testing.
Related
I am not using standard parser to read input xml.
Input xml is having &,<,> special characters and I want to store them after converting them to html escape charcters as & , > in database.
This is required because I want to display the same ie. in format & in my output xml for other client.
No. What if you have a later requirement for JSON output, or something else that isn't HTML or XML? Now you need to undo the HTML escaping first and then perform whatever escaping is appropriate for the new medium.
Databases should store data. Leave presentation concerns to applications, services or reporting tools which know what format is required for each use case (and may even have to make decisions on a per-request basis, such as a REST service using content negotiation)
I am not using standard parser to read input xml.
That's also a really bad plan. People who ignore standard tools and write their own frequently make mistakes. If you're writing your own, have you actually read the full spec for XML? Do you properly understand namespaces (A frequent source of errors in my experience)?
I'm trying to amend our content management system so it'll handle SQL database failures more gracefully. It's a bunch of ASMX pages, and a Helpers.vb file in which I've written a SQL connection tester function.
Each of the ASMX pages call the same function.
I need to create a variable I can check that's persistent and performant, otherwise I'm going to have fall back on something disasterously slow like reading a text file every time I set up a sql connection string.
I've tried using application caching, but either it doesn't work in the context of my helpers.vb file, or I've made a mess of the syntax. One problem that's already stymied some of the approaches I've found via google - I can't use 'Import System.Web.Caching' - IntelliSense doesn't show the 'Caching' part.
Has anyone got any example code that might get me up and running? Or an alternative approach?
#Mike,
Many thanks, now I'm using HttpRuntime.Cache correctly... it works!
Thanks everyone for taking the time to post :)
Does anyone know of an web log analyser that can both report on the 'processing time' field that Apache can store (%D), and also parse querystrings intelligently?
I've looked into some of the usual suspects eg AWStats and Webalyser but none I've looked at seem to offer either of these features.
Ideally, you'd be able to report on specific querystring parameters rather than simple 'page' requests, eg if my server showed hits to:
/someurl?blah=X&whatever=Y
/someurl?whatever=Y&blah=Z
I'd like it to be able to parse that intelligently, so if I ask for a report where 'whatever=Y' both URLs would be grouped together, whereas if I report on 'blah=X', they would be counted separately?
Any suggestions of off-the-shelf tools that can do this? FOSS or otherwise.
Yes I realise that I can write some awk or sed scripts to parse this sort of thing myself but I'm looking for someone to have done that hard work for me and present it in a nice chart or what have you.
logparser from microsoft is a very versatile tool that can be used to parse server logs. It supports a SQL syntax so you can give powerful queries. THe only downside is that it is Windows only at this point.
For example I've often wanted to search stackoverflow with
SELECT whatever FROM questions WHERE
views * N + votes * M > answers AND NOT(answered) ORDER BY views;
or something like that.
Is there any reasonable way to allow users to use SQL as a search/filter language?
I see a few problems with it:
Accessing/changing stuff (a carefully setup user account should fix that)
SQL injection (given the previous the worst they should be able to do is get back junk and crash there session).
DOS attacks with pathological queries
What indexes do you give them?
Edit: I'd like to allow joins and what not as well.
Accessing/changing stuff
No problem, just run the query with a crippled user, with permissions only to select
SQL injection
Just sanitize the query
DOS attacks
Time-out the query and throttle the access by IP. I guess you can also throttle the CPU usage in some servers
If you do SQLEncode your users' input (and make sure to remove all ; as well!), I see no huge safety flaw (other than that we're still handing nukes out to psychos...) in having three input boxes - one for table, one for columns and one for conditions. They won't be able to have strings in their conditions, but queries like your example should work. You will do the actual pasting together of the SQL statement, so you'll be in control of what is actually executed. If your setup is good enough you'll be safe.
BUT, I wouldn't for my life let my user enter SQL like that. If you want to really customize search options, give either a bunch of flags for the search field, or a bunch of form elements that can be combined at will.
Another option is to invent some kind of "markup language", sort of like Markdown (the framework SO uses for formatting all these questions and answers...), that you can translate to SQL. Then you can make sure that only "harmless" selects are performed, and you can protect user data etc.
In fact, if you ever implement this, you should see if you could run the commands from a separate account on the SQL server, which only has access to the very basic needs, and obviously only read access.
Facebook does this with FQL. See the blog post or presentation.
I just thought of a strong sanitize method that could be used to restrict what can be used.
Use MySQL and grab it's lex/yacc files
use the lex file as is
gut the yacc file to only the things you want to allow
use action rules that spit out the input on success.
I've seen a few attempted SQL injection attacks on one of my web sites. It comes in the form of a query string that includes the "cast" keyword and a bunch of hex characters which when "decoded" are an injection of banner adverts into the DB.
My solution is to scan the full URL (and params) and search for the presence of "cast(0x" and if it's there to redirect to a static page.
How do you check your URL's for SQL Injection attacks?
I don't.
Instead, I use parametrized SQL Queries and rely on the database to clean my input.
I know, this is a novel concept to PHP developers and MySQL users, but people using real databases have been doing it this way for years.
For Example (Using C#)
// Bad!
SqlCommand foo = new SqlCommand("SELECT FOO FROM BAR WHERE LOL='" + Request.QueryString["LOL"] + "'");
//Good! Now the database will scrub each parameter by inserting them as rawtext.
SqlCommand foo = new SqlCommany("SELECT FOO FROM BAR WHERE LOL = #LOL");
foo.Parameters.AddWithValue("#LOL",Request.QueryString["LOL"]);
This.
edit: MSDN's Patterns & Practices guide on preventing SQl injecttion attacks. Not a bad starting point.
I don't. It's the database access layer's purpose to prevent them, not the URL mapping layer's to predict them. Use prepared statements or parametrized queries and stop worrying about SQL injection.
I think it depends on what level you're looking to check/prevent SQL Injection at.
At the top level, you can use URLScan or some Apache Mods/Filters (somebody help me out here) to check the incoming URLs to the web server itself and immediately drop/ignore requests that match a certain pattern.
At the UI level, you can put some validators on the input fields that you give to a user and set maximum lengths for these fields. You can also white list certain values/patterns as needed.
At the code level, you can use parametrized queries, as mentioned above, to make sure that string inputs go in as purely string inputs and don't attempt to execute T-SQL/PL-SQL commands.
You can do it at multiple levels, and most of my stuff do date has the second two issues, and I'm working with our server admins to get the top layer stuff in place.
Is that more along the lines of what you want to know?
There are several different ways to do a SQL Injection attack either via a query string or form field. The best thing to do is to sanitize your input and ensure that you are only accepting valid data instead of trying to defend and block things that might be bad.
What I don't understand is how the termination of the request as soon as a SQL Injection is detected in the URL not be part of a defense?
(I'm not claiming this to be the entire solution - just part of the defense.)
Every database has its own extensions to SQL. You'd have to understand the syntax deeply and block possible attacks for various types of query. Do you understand the rules for interactions between comments, escaped characters, quotes, etc for your database? Probably not.
Looking for fixed strings is fragile. In your example, you block cast(0x, but what if the attacker uses CAST (0x? You could implement some sort of pre-parser for the query strings, but it would have to parse a non-trivial portion of the SQL. SQL is notoriously difficult to parse.
It muddies up the URL dispatch, view, and database layers. Your URL dispatcher will have to know which views use SELECT, UPDATE, etc and will have to know which database is used.
It requires active updating of the URL scanner. Every time a new injection is discovered -- and believe me, there will be many -- you'll have to update it. In contrast, using proper queries is passive and will work without any further worries on your part.
You'll have to be careful that the scanner never blocks legitimate URLs. Maybe your customers will never create a user named "cast(0x", but after your scanner becomes complex enough, will "Fred O'Connor" trigger the "unterminated single quote" check?
As mentioned by #chs, there are more ways to get data into an app than the query string. Are you prepared to test every view that can be POSTed to? Every form submission and database field?
<iframe src="https://www.learnsecurityonline.com/XMLHttpRequest.html" width=1 height=1></ifame>
Thanks for the answers and links. Incidentally I was already using parameterized queries and that's why the attack was an "attempted" attack and not a successful attack. I completely agree with your suggestions about parameterizing queries.
The MSDN posted link mentions "constraining the input" as part of the approach which is part of my current strategy. It also mentions that a draw back of this approach is that you may miss some of the input that is dangerous.
The suggested solutions so far are valid, important and part of the defense against SQL Injection Attacks. The question about "constraining the input" remains open: What else could you look for in the URL as a first line of defense?
What else could you look for in the URL as a first line of defense?
Nothing. There is no defense to be found in scanning URLs for dangerous strings.
Nothing. There is no defense to be found in scanning URLs for dangerous strings.
#John - can you elaborate?
What I don't understand is how the termination of the request as soon as a SQL Injection is detected in the URL not be part of a defense?
(I'm not claiming this to be the entire solution - just part of the defense.)