I have a suite of Oracle Apex based applications due to have a security test. Does anyone have any tips on what I should look for to tighten things up?
The thing with Apex applications is that the underlying code is all PL/SQL, so it is no surprise that the major class of vulnerability affecting Apex application is SQL Injection.
You need to make sure that you do not use substitution variables (e.g. &P1_TEST.) as these almost always lead to exploitable injection. When they are used within PL/SQL begin/end blocks the injection is very "powerful" as an attacker can specify an arbitrary number of PL/SQL statements.
Many Apex apps use dynamic SQL (where a query is constructed in a string and then executed), either through direct calls to EXECUTE IMMEDIATE or through Apex FUNCTION_RETURNING_SQL blocks. Dynamic SQL is almost always a bad idea.
You'll also find quite a bit of Cross-Site Scripting in Apex apps, where input from users, or from queries run against the database is not escaped. The various Apex reports provide settings to enable escaping but these may not have been chosen when the report was defined.
Also consider the access-control model and ensure all the pages are protected with appropriate authorisation schemes. Do not use the APEX_APPLICATION_FILES table if you're storing uploads as that doesn't protect against unauthenticated downloads.
Hope that helps, and good luck!
Related
My needs are very similar to this question about where to store business logic and this question about managing SQL code in a data table. But I would like more specific tips on how to manage the risks of SQL injection and Sandboxing that are alluded to in the answer to that second question.
My applications deal with data submissions that involve thousands of validation rules which need to be updated frequently. I would like to manage these rules as error conditions (formatted as SQL "WHERE" clauses) stored in a data table (ex: "Total != Column1 + Column2"). I would like analysts skilled in SQL to have access to directly insert and update these business rules, either in Management Studio or through an intranet application. One or more intranet applications or SQL processes would then use the error clauses in that table to validate data stored in other tables in the database.
Is it fundamentally a bad approach to save arbitrary code to a
database, even if access to that table is restricted to a small
number of users?
As my applications execute SELECT statements using the retrieved
WHERE clauses, is there an effective, reliable way to limit the
access rights of any malicious code pulled from the database? (I'm
not confident that I can reliably sanitize a retrieved WHERE clause.)
Is there a better place to store frequently updated business logic,
that is similarly simple to manage, but with better security?
Where can I go to find general principles about managing executable code
in a database?
Given this statement of yours:
I'm not confident that I can reliably sanitize a retrieved WHERE clause.
The answer to the following question is "yes."
Is it fundamentally a bad approach to save arbitrary code to a database, even if access to that table is restricted to a small number of users?
Don't rely on restrictive access privileges. An attacker can cause mischief (at least denial of service) using only SELECT privilege -- or even no privilege at all.
I agree with the comment from #WayneConrad, that you would be more secure if you design your business logic in a DSL, and then write code to interpret your own DSL and convert it into a limited set of WHERE clauses. By parsing and validating your own DSL, you have a greater likelihood of blocking malicious code (unless your DSL becomes too flexible).
You're going to have to write a parser and validator, either for SQL or for a DSL. There's no other way to do this with any kind of security.
There are many PHP frameworks available for PHP namely -
Zend
CakePHP
CodeIgniter
Symfony
and so on....
Which are the security related issues taken care of by most of the frameworks ?
( As far as i know ( Cross-site scripting (XSS)) vulnerability is handled by most of them if we use there methods. What are the other issues taken care by most of them ? )
Along with usage of framework in a project, what are other security concerns needs to be taken care of ?
EDIT: In my case i am using codeigniter framework.
[spam]
I've created a little overview table a while back: http://matrix.include-once.org/framework/ which includes a few summaries about the basic cornerstones of web app security:
DB escaping / or parameterized SQL (e.g. via ORMs)
input filtering / sanitization
output encoding
authorization hash function (if any)
separation of frontend and admin backend (not completed, mostly n/a)
If I wanted to generalize, the big frameworks do indeed cover a lot of that. So the real issues become logical oversights in the business/processing layer.
Well this is a bit of a vague question as it entirely depends on what framework you are talking about.
All of the frameworks you have listed use a database abstraction layer of some sort, be it a simple query builder or a larger ActiveRecord/ORM implementation. These database abstraction layers will stop SQL injection most of the time.
CodeIgniter provides a Encrypt class which will help you generate passwords and random strings. In your main config file is an "encryption key" which will be specific to your application. This means your application will have a unique salt to another application, so if somebody gets a copy of/access to your database they won't be able to work out the passwords.
There are plenty of other security features specific to each framework, but those are the basics.
No matter how much attention and thought has gone into making sure a PHP framework is secure, the reality is that there is always room for improvement and even though frameworks like Codeigniter provide XSS, input filtering, request validation, database abstraction and other nice things, there will always be bugs and issues.
Never solely rely on a framework's in-built security protection methods. Always read into how a framework does something, understand the logic and then rewrite to meed your needs if you find something isn't as secure as it should be.
However, having said the above, I have been using Codeigniter for a few months and in a couple of high-end, high-trafficked websites and can't say that I have experienced any security issues or breaches. The one true advantage of a framework when it comes to security is that they're probably protecting you from some kind of attack you never knew existed in the first place (which is an awesome bonus).
Read into how Codeigniter and other frameworks solve security issues and protect your applications, you'll find it will strengthen your development knowledge and benefit you in the future when you write large-scale applications that require tough security and high reliability.
As far as know, I must be careful with PHP, and I think Javascript. What else?
Security vulnerabilities are (mostly) independent of the language involved (except for memory issues).
Instead, you should focus on tasks with potential vulnerabilities, such as processing user input or handling sensitive data.
Some things to watch out for:
Always use parameters in SQL
Always escape correctly (when generating HTML, JSON, Javascript strings, or anything else)
Be extremely careful when executing code dynamically (eg, eval, automatic updates, etc)
Always validate user input on the server
You should also read articles about security, such as the Top 25 Most Dangerous Programming Errors.
OWASP provides an annual report describing the top ten web application security flaws (see link below for description of the project and the most recent report). As SLaks wrote, many vulnerabilities are independent of the language. Web applications need to be designed with security in mind.
http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
Mistakes in memory management in C, C++, and their ilk are well known. I mostly program in dynamic, weakly typed languages. Are there issues which are particularly important in languages of this type? What language specific issues might I keep an eye out for?
I'm generally mindful of standard security issues, and try to think about the ways in which code could be misused, but am sure there are plenty of less superficial mistakes I could be making, and am interested in expanding my knowledge in this area.
If you use anything similar to eval() then there is risks for attacks, esp if you are trusting something from outside your application.
Just because you're not writing the lower level code doesn't mean that the language you are using, and therefore your app, wont have these kinds of security problems. So my answer to your question is to ensure that you stay up to date on the latest releases on whatever tools you are using. This is more of an issue for you if you host the environment in which your app run, otherwise it's more of a problem for users of your app if they have to run it on their machines.
SQL Injection is a common attack which doesn't depend on type management. Generally, missing input validation is a very common reason for security issues.
In the case of JavaScript the main vulnerabilities according to the EC-Council Secure Programmer Vol.1 are the following:
Cross Site Scriptting (XSS). In a XSS
attack, attackers submit client-side
executable scripts by inserting
malicious Javascript, VBScript,
ActiveX, HTML or Flash into vulnerable
dynamic page and execute the script on
the user's machine to collect the
user's information.
Avoiding XSS:
Constrain Input:
Define a codepage that decide wich characters are problemetic,
Restrict variables to choose characters that are explicitly allowed.
Filter metacharacters depending on the interpreter (HTML, browser and file system)
Aply canonicalization:
- The canonicalization technique brinbgs the input to an appropiate from before validating the input.
Validate de input:
Validate all external input for field length, data type, range, and for a white list to ensure acceptance of onlyknown unproblematic characters.
Encode Output
Convert metacharacters e.g: <, >, and "",use HTML entities instead.
Encode user-supplied output so that any inserted script are prevented from being transmitted to users in an executable form.
JavaScript Hijacking: Allows an
unauthorized party to read
confidential information. Occurs
because most web-browsers that
implement a security model do not
anticipate the use of Javascript for
communication. JavaScrpt Hijacking is
generally carried out through
cross-site request forgery. Coss-site
request forgeryis an attack that
enables the victim to sumbit one or
more HTTP requests to a vulnerable
website. This attack compromises data
integrity and confidentiality, meaning
an attacker can read the victim's
information and modify the information
stored on the vulnerable site.
A Javascript Hijacking attack can be defended:
By declinig malicious requests.
By preventing direct execution of the JavaScript response.
My company has a requirement that all production sites pass an AppScan security scan. Sometimes, when we scan a SharePoint installation, the software detects a blind SQL injection vulnerability. I'm pretty sure this is a false positive--AppScan is probably interpreting some other activity in the HTTP response as success of the blind injection. But it's difficult to prove that this is the case.
I suspect that SharePoint, both MOSS 07 and WSS 3.0, uses stored procedures exclusively behind the scenes. Does anyone know if there is any documentation from Microsoft to this effect, and furthermore, whether any of the stored procedures use dynamically-generated SQL? If everything were sprocs, and none of them dynamic, we would have pretty good evidence that SharePoint has no SQL injection vulnerability.
They aren't all stored procs. In particular, things like cross-lists joins produce some horrendous syntax. For an example, look at the SQL Trace window from this article. Also, since both user controls and API calls can be written by developers, there is no guarantee that you aren't subject to SQL Injection if you are using custom modules.
My guess would be that SharePoint always uses, at the very least, named parameters. However, your best option might to be running a SQL trace and comparing the results. Also, if you are a large enough customer, you might just try calling your local MSFT evangelist (or posting a question on connect.microsoft.com) and seeing if you can get a response.
Thanks. I looked at the profiler myself and found some things:
It looks like SharePoint is only executing stored procedures. There are occasional bits of pure SQL, but these seem to be limited to "exec sp_oledb_ro_usrname" and "select collationname(...)", which appear to be some deep-down internal thing, and possibly are not being executed as SQL at all, but are just coming out in the profiler that way...?
SharePoint does occasionally use sp_executesql, but this is a parameterized call and is therefore probably safe from injection.
There's a number of relatively new blind SQL injection vectors which are based on response delay - for example using WAITFOR DELAY. At least sqlmap and BurpSuite use them (and others probably too).
These vectors however are prone to false positives, because the trigger is, well, HTTP response delay, which may also happen for thousand other reasons if you're scanning over Internet. If you got these over LAN, I would be more suspicious but still investigate other possible delay causes on the server side. Only if you get the delay consistently in a number of independent tried, you are probably dealing with a vulnerability.
Also note that SharePoint often triggers old FrontPage vulnerabilities in many vuln scanners, which are also false positives - for details see this article "SharePoint and FrontPage Server Extensions in security scanner results".