Tag Info

Hot answers tagged

53

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 ...


21

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 ...


18

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 ...


18

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 ...


17

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. ...


17

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 ...


15

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, ...


15

Short answer: To prevent brute forcing the CSRF token. Let's take a trivial example: let's say your token is a single digit, accepting values from 0 to 9. Now sure, an attacker cannot read this value from the cookie or header, but she does not have to - she can just have the attack send 10 CSRF requests, one with each possible value. One of them will be ...


14

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

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 ...


13

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.


13

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

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

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 ...


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

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


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 ...


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 ...


9

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 ...


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

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 ...


8

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 ...


8

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 ...


8

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.


8

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 ...


8

No, that's not necessarily sufficient. There are many XSS vectors that can potentially still be applied, depending upon where the injection point is. Some examples: Injection into unquoted attribute values Injection into attribute values quoted with a single quote (' instead of ") Injection into CSS Injection into Javascript Injection into comments ...


7

Yes, grab fuzzdb from http://code.google.com/p/fuzzdb/: fuzzdb helps identify security flaws in applications by aggregating known attack patterns, predictable resource names, and server response messages to create a comprehensive, repeatable set of malformed input test cases. fuzzdb has a great list of attack payloads.


7

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 ...



Only top voted, non community-wiki answers of a minimum length are eligible