Hot answers tagged owasp-top-ten
42
XSS - Cross Site Scripting (but not limited to actual cross site scripting)
XSS is usually presented in 3 different ways:
Non-persistent (often called reflected XSS)
This is when you are able to inject code and the server returns it back to you, unsanitized. Often this can be exploited by distributing an (usually innocent looking) URL in some form or ...
16
Already very good answers on this question, however I would like to mention some more:
Secure coding (which is already been mentioned by many already)
Escaping user input
Parameterized queries (prepared statements, predefined queries where you only bind
variables)
Code defensively
Monitoring for attacks
Network Intrusion Detection System (NIDS)
Host ...
16
I agree with @Jorn's answer about the validation.
However, you're still forgetting a very important step here, and that is output encoding.
E.g. HTML encoding (or Attribute encoding, or Javascript encoding, etc) before outputting anything... In fact, this is arguably even more important than the input validation (arguably, not absolutely, and definitely ...
14
In PHP you cannot stack querys with a semicolon. However you can nest a query into another with parentheses (commonly called subqueries), e.g.:
SELECT * FROM vulnerable_table WHERE id = (SELECT number from other_table)
Using this technique (disregarding whether you output your SQL result or not) a keen attacker may extract all data from your database.
...
14
Yes, it is important to include anti-forgery tokens for login pages.
Why? Because of the potential for "login CSRF" attacks. In a login CSRF attack, the attacker logs the victim into the target site with the attacker's account. Consider, for instance, an attack on Alice, who is a user of Paypal, by an evil attacker Evelyn. If Paypal didn't protect its ...
13
The best way to build CSRF protection properly:
Don't.
Most common frameworks have this protection already built in (ASP.NET, Struts, Ruby I think), or there are existing libraries that have already been vetted. (e.g. OWASP's CSRFGuard).
Another option, depending on your context, is to enforce reauthentication of the user, but only for specific, ...
13
For input validation, I recommend a whitelist approach combined with pass-or-reject. So define what is valid, and accept only valid input, reject everything else.
If you build a rich text editor that sends html to your server, you can use JavaScript to sanitize the input, so that pasting html from Word could end up working. Yet your server won't accept any ...
13
I'm assuming your using standard PHP mysql_query function in which case something like this would be effective in your example.
SELECT price FROM products WHERE 1=1 AND id=
999999999999999999999999
UNION ALL
(SELECT CONCAT(username, ' ', password) FROM user) limit 0, 1;
Explanation
Use an ID of a product that is not going to exist.
UNION with ...
12
JavaScript is a client-side language.
In my professional opinion trusting ANY client-side implementation for added security is a waste of time, and the implementation would be a gross waste of resources.
Your time, and money would be better utilized implementing proper input cleansing and validation on the server-side environment.
12
1. Backdoor testing accounts.
Engineers often include backdoor mechanisms and testing accounts in hardware for debugging purposes, with trivial or no security measures put in place to protect them. Unfortunately, a large number of devices make it to market without having these mechanisms and accounts disabled, allowing attackers to gain illegitimate access ...
11
There is a good explanation on OWASP: OWASP CSRF Prevention Cheat Sheet
In short they say that there are two ways:
Add a random token to each user session. Only if this token is present and correct will the changes be applied, otherwise the request should be rejected. It is important that the token is only sent with a POST request, since GET requests can ...
11
No, you are not automatically safe.
SQL Injection can still exist.
From the OWASP page:
A note about SQL injection
Since it is the hot topic, I will
address it now but discuss in detail
later.
Hibernate does not grant immunity to
SQL Injection, one can misuse the api
as they please.
There is nothing
special about HQL ...
11
As long as you use dynamic SQL, SQL-Injection stays an open attack vector. If you want to secure against SQL-Injection, the way to go is by using parametrized queries. I suspect you are using PHP+MySQL, so this would be an example of a parametrized query.
$dbh = new PDO('mysql:host=localhost;dbname=example', 'user', 'password');
$sth = ...
10
The key defence is to only use API's that securely escape database queries - these are generally referred to as parameterised or prepared statements. These can't be used in all cases (for example where a SQL identifier such as the table or column name is supplied at runtime), but is the best approach where possible (the majority of cases).
Note - this can ...
10
There is not a top 1000, because that wouldn't actually be relevant to most people. The OWASP top 10 are chosen because they are applicable across the vast majority of web applications, and are likely to be exploited if you do not secure them.
Beyond that, if you are starting from a position of already having applications and infrastructure:
Understand ...
10
My experience is it depends on industry, regulations, and business relationships (not necessarily company size).
Examples:
<10 person company, building a web app that retrieves credit
history, they were required by business partners to have a full
webapp pentest
<50 person company, building a web portal allowing
customers to view point of sale ...
9
To piggy-back on what SteveSyfuhs said, there are many possible malicious ways XSS can be used.
Examples:
One example would be to inject malicious code into a database field. Subsequently, any time that field is displayed to the end-user unsanitized, their browser would execute the code. This is called Persistent/Stored Cross Site Scripting.
Another would ...
9
Short answer : NO.
It is indeed shocking to know that most companies do not care about the security stature of their product or are ignorant about it. Usually, the QA teams in these companies perfrom the testing, and maybe the test cases would include some attack vectors for XSS, SQLi etc. But I'm pretty sure that they would not have a dedicated process ...
8
Here you can find some SQL Injection Resources
Here are some SQL injection attacks by example
And here are some basics how to protect your application against SQL injection
The main step to protect web application against SQL injection is to properly sanitize any user input (especially input used in SQL queries). In some languages/frameworks, there are ...
8
If you really want to understand XSS, I strongly recommend OWASP's XSS Prevention Cheat Sheet. It's not focused on hacking, it's focused on helping developers prevent these problems in the first place. http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
7
It seems like an interesting idea to me but since you're asking about problems with it I'll respond with some of the obvious ones. I don't see how this can be applied globally to most sites, as most would seem to need many of the dangerous javascript functions available for core functionality. E.g. onmouseover, href="javascript:alert(1)", etc. For this to ...
7
If your company is in any way a part of regulations requiring security (like SOX or HIPPA in the US) or trade standards (like PCI or various ISO standards), all you have to do is tell them that:
you've found holes that could let anyone download the entire database and network (stretch the truth a bit if you have to sell it, and remind them of the ACS:Law ...
7
Have you seen the work of Mozilla Security's Content Security Policy (summary)?
This is the specification.
Content Security Policy is intended to help web designers or server administrators specify how content interacts on their web sites. It helps mitigate and detect types of attacks such as XSS and data injection. CSP is not intended to be a main line ...
7
CSRF or Cross-Site Request Forgery is basically a bad person tricking a good person's browser into performing functions on your website on the bad persons behalf.
Here is an example:
Good user logs into your website and
obtains a valid session
Bad user tricks good user into
following a link to a malicious site
Malicious
site contains a ...
7
To avoid client-side security issues, you need to learn about the security requirements for client-side code and the common mistakes. OWASP has good resources. Make sure you read about DOM-based XSS, as that is one of the most common security mistakes.
As far as security best practices, I have several suggestions:
To avoid XSS, abide by the rules found ...
6
Restricting the whitelist to the <head> element is not helpful because <title> is part of <head> and often contains user provided data. So the whitelist definition needs to be the first element in <head> and only the first whitelist call may be accepted.
The content of <li>example 1</li> is not trusted in the example. So an attacker could ...
6
XSS usually works by injecting foreign Javascript into the body of the trusted page. If you trust your code that says document.allowJavaScript(['div.outer', '#list', 'a.test']); how would you not trust code on the other page of the site saying document.allowJavaScript(['div.evil', '#securityhole', 'a.exploit']); which is produced by an XSS vulnerability? As ...
6
Here are two very easy to understand example of XSS
http://www.virtualforge.de/vmovie/xss_lesson_1/xss_selling_platform_v1.0.html
http://www.virtualforge.de/vmovie/xss_lesson_2/xss_selling_platform_v2.0.html
Everyone with a litte background in HTTP and web should be able to understand it.
6
If you're only trying to convert links, the safest option is to use sanitization and a whitelist. Basically a list of allowed values, which prevents anything you don't specify from being passed. Always use a reputable sanitization function and whitelist, I would not recommend building your own unless you know what you're doing. See a page like the ...
Only top voted, non community-wiki answers of a minimum length are eligible
