The OWASP definition of injection attacks says that -
Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
What does interpreter means in each case (LDAP, OS, SQL etc)? Is an interpreter needed for all types of injection attacks such as XML, XPath, HTTP etc?
Yes, the nature of a code injection attack is that the attacker tricks the application into running some code statements that are not part of the intended functions of that application.
This means there has to be some mechanism to parse and execute the malicious code contained in the attacker's payload before the owner of the application can stop it.
In theory, an application could compile code and run it automatically, but it's much more common for this type of attack to use malicious code that is not compiled, but is interpreted at runtime.
Your other examples, XML, XPath, HTTP, are not typically associated with code injection.
XML is not code, it's a data format.
HTTP is not code, it's a protocol.
XPath is sort of like code, but a very specialized type of code. It's an expression language to identify elements in an XML document. It's limited in what it can do, so it's not a common vector for code injection attacks.
Related
I am a newbie in web application development. My application is using AngularJS\NodeJS. A security tool reported reflected XSS vulnerability in our application. From my search on the internet I found that there is a HTTP X-XSS-Protection response header which appears to protect the application against reflected XSS attacks. However, I am not sure if that should be sufficient for handling the reflected XSS attacks or additionally any input sanitization should also be done in the application.
X-XSS-Protection is not enough, and is already enabled by default in most browsers. All it does is it enables the built-in XSS protection in browsers, but the trick is, to the best of my knowledge (maybe somebody will correct me) it is not specified what exactly the browser should do. Based on my experience, browsers only filter the most trivial XSS, when there is a parameter with javascript between script tags - such javascript from the parameter will not be run. For example if the parameter is
something <script>alert(1)</script> something
this will not be run by the browser. And apparently that's it.
For example if you have server-side code like
<div class="userclass-{{$userinput}}">
then this can be exploited with the string abc" onclick="alert(1)" x=", and this will go through the built-in filter in any browser I tried.
And then we haven't talked about stored or DOM XSS, where this protection is totally useless.
With Angular, it is slightly harder to make your code vulnerable to XSS (see here how to bind stuff as html for example), but it is by far not impossible, and because you would almost never need an actual script tag for that, this built-in protection has very limited use in an Angular app.
Also while input validation/sanitization is nice to have, what you actually need against XSS in general is output encoding. With Angular, that is somewhat easier than with many other frameworks, but Angular is not the silver bullet, your application can still be vulnerable.
In short, anytime you display user input anywhere (more precisely, anytime you insert user input into the page DOM), you have to make sure that javascript from the user can't be run. This can be achieved via output encoding, and secure Javascript use, which can mean a lot of things, mostly using your template engine or data binding in a way that only binds stuff as text, and not anything else (eg. tags).
What X-XSS-Protection does is browser dependent and can't be relied upon for security. It is meant as an extra layer to make it more difficult to exploit vulnerable applications, but is not meant as a replacement for correct encoding. It is a warning that an application is vulnerable and the responsibility to fix it is on the application developers.
This is why in Chrome, errors in the XSS filter are not even considered security bugs. See the Chrome Security FAQ:
Are XSS filter bypasses considered security bugs?
No. Chromium contains a reflected XSS filter (called XSSAuditor) that
is a best-effort second line of defense against reflected XSS flaws
found in web sites. We do not treat these bypasses as security bugs in
Chromium because the underlying issue is in the web site itself. We
treat them as functional bugs, and we do appreciate such reports.
The XSSAuditor is not able to defend against persistent XSS or
DOM-based XSS. There will also be a number of infrequently occurring
reflected XSS corner cases, however, that it will never be able to
cover. Among these are:
Multiple unsanitized variables injected into the page.
Unexpected server side transformation or decoding of the payload.
And there are plently of bugs. There are ways found to bypass the filter regularly. Just last week there was a fairly simple looking injected style attribute bypass.
Such a filter would need to tell where values in the output have come from by only looking at the input and the output, without seeing any templates or server-side code. When any processing is done to the input, or there's multiple kinds of decoding occurring, or multiple values are combined together, this can be very difficult.
Much easier would be to take care of the encoding at the template level. Here, we can easily tell the difference between variable values and static code because they haven't been merged together yet.
You can't write secure sites with Java because the source code can be examined, does PHP fix this problem? What should I pick up and look to to find out how to write a web server that can handle payments, like with Bitcoin or an0ther protocol?
1. Don't rely on difficulty of reverse-engineering to maintain security.
Every language can be reverse-engineered, whether it produces native assembly code, Java byte code or is a scripting language such as PHP or Javascript. The final product of any coding language, whether script or byte code, can usually be obfuscated to make attempts at reverse-engineering more difficult BUT REVERSE-ENGINEERING WILL NEVER BE IMPOSSIBLE.
2. Don't rely on obscurity of source code to maintain security.
How difficult a language is to reverse-engineer, however, holds no bearing on whether that makes it a good or bad candidate for programming a web server. As long as your server is secure, your server code will not leak out.
Best practices dictate that your server security should not rely on any secrets in your code. Even if your code were to leak out and be accessible by the public, it should not affect the security of your web server as long as it is properly coded (no secrets stored in code and no vulnerabilities).
Your secrets, such as password hashes, should be stored in a shared (shared between instances of your web server) database or some other form of shared secure storage.
In some cases, your code may contain vulnerabilities, and exposing the code to the public may reveal these vulnerabilities. This is generally considered A Good Thing. Whether or not vulnerabilities are known to the public, they will still exist until they are fixed in the code. Public review helps to identify these vulnerabilities early on (allowing them to be fixed and the vulnerabilities eliminated) instead of allowing them to be surreptitiously exploited.
3. Combine IT best practices with coding best practices to create and maintain a secure server.
Maintaining a secure server requires not only wise coding but wise IT practices. Ultimately, selecting the best language for a web server should be more a case of selecting the best tool for the job, or the one you are most comfortable with.
Consider posting security questions to https://security.stackexchange.com/
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!
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.