The most Important Security Controls Missing in Javaee--reference

Java EE have some excellent built-in security mechanisms, but they don ' t come close to covering all the threats that your AP  Plications'll face. Many common attacks like Cross-site Scripting (XSS), SQL injection, Cross-site Request forgery (CSRF), and XML eXternal En  Tities (XXE) aren ' t covered at all. Can prevent your Web applications and Web services from being vulnerable to these attacks, but it's going to take some  Work and testing. Fortunately, the Open Web Application Security Project (OWASP) has issued the ' Ten most Critical Web application security Risks "report.

Let's take a look at how these important risks apply to Java EE Web applications and Web services:

1. Injection-  injection happens any time a developers takes  untrusted information, such as Request.getparameter (), Request.getcookie (), or Request.getheader (), and uses it in a command interface.  for example, SQL injection happens if you concatenate untrusted data to a regular SQL query, like ' select * from u Sers WHERE username= ' "+ request.getparameter (" user ") +" ' and password= ' "+ request.getparameter (" pass ") =" ' ";  developers should use PreparedStatement to keep attackers from changing the meaning of queries and taking over Datab ASE hosts.  there is many other types of injection such as Command injection, LDAP injection, and Expression Language (EL) Inje Ction, and all of them is devastatingly dangerous, so is careful when sending data to these interpreters.

2. Broken authentication and Session management–  javaee have support for authentication and Sessi On management, but there is many ways to go wrong here. You'll have the make sure-all authenticated traffic goes over SSL, no exceptions.  if you ever expose a jsessionid it can is used to hijack a user ' s session without their knowledge.  you should rotate the jsessionid when the user authenticates to prevent Session fixation attacks.  and should avoid the use of response.encodeurl () which adds the user's jsessionid to the URL where it can be mor E easily disclosed or stolen.

3. Cross-site Scripting (XSS)-  xss occurs when Java EE developers take untrusted information from The HTTP request and put it in the HTTP response without proper contextual output encoding.  the attacker can use this behavior to inject their scripts into a website where they can hijack sessions and steal D Ata.  to prevent these attacks, developers need to perform context-sensitive output encoding.  if you ' re putting data to HTML, use & #xx; Format. Be sure to quote your HTML attributes, as unquoted attributes can is terminated with many different characters.  if you ' re putting untrusted data into Javascript, URLs, or CSS, use the appropriate escaping technique for each.  and be very careful when dealing with nested contexts, such as a URLs in Javascript in an HTML attribute. You'll want an encoding library like OWASP Esapi to help.

4. Insecure Direct Object references–  anytime Your application exposes an internal identifier, s Uch as a database key, a filename, or HashMap index, attackers may attempt to manipulate those identifiers to access Unaut horized data.  for example, if you pass untrusted data from the HTTP request to the Java File constructor, the attacker could use ". /"or null byte attacks to trick your validation. You should consider using Indirect references to your data, to prevent this type of attack. The ESAPI Library has support for referencemaps that facilitate this indirection.

5. Security misconfiguration–  there is a lot of Security settings in modern Java EE applications and frameworks like Struts and Spring. Is sure you has reviewed them and set things up the the-the-same.  for example, beware the only  applies to the listed methods, allowing Attackers to use other HTTP methods, such as HEAD and PUT, to bypass the entire security constraint.  most likely you should delete

6. Sensitive Data exposure–  java have extensive cryptographic libraries, but they is not easy to Use correctly. You should find a library, the builds on top of the JCE to provide easily and safely usable cryptographic methods. Some examples is Jasypt and ESAPI.  you should be using the strong algorithms like AES for encryption and SHA256 for hashes.  be careful with password hashes as they can is reversed using a Rainbow Table, so use adaptive algorithms like BCRYP T or PBKDF2.

7. Missing Function level Access control –  Java EE supports both declarative and Programmatic access control, but many applications still choose to create their own scheme. Frameworks like Spring also has annotation-based access control primitives. The most important thing are to being sure that every exposed endpoint have the appropriate access control check, including web Services.  don ' t assume that your client can control anything, as attackers would access your endpoints directly.

8. Cross Site Request Forgery (CSRF)  -  every state-changing endpoint needs to verify that re Quests is not forged. Developers should put a random token in each user's session and then verify it when requests arrive. Otherwise, attackers can create "attack" pages by including malicious IMG, SCRIPT, FRAME, or FORM tags which link to the UN Protected application. When the victim views such a page, their browser would generate a "forged" HTTP request to whatever URL was specified in the tag, and would automatically include the victim ' s credentials.

9. Using components with known vulnerabilities–  modern java EE applications have hundreds of LIBR Aries. Dependency resolution tools like Maven has caused this number to explode in the past five years.  many widely used Java libraries Haveknown Vulnerabilities that can allow a Web application using them to be COM Pletely subverted.  the solution is to stay on top of the your libraries and keep them up to date. Don ' t just run a single scan, as new vulnerabilities is released every day.

unvalidated redirects and forwards- Anytime your application uses untrusted data, such as a request.getparam Eter () or Request.getcookie (), in a-call to Response.sendredirect (), the attacker-be able-force a victim ' s browser  To a untrusted website designed to install malware. A similar problem exists with forwards, except that the attacker is able to forward himself to unauthorized functional  ity, such as administrative pages. Be sure to carefully validate redirect and forward targets.

You should stay on top of these problems continuously. New attacks and vulnerabilities is identified all the time. Ideally, you'll integrate security checks into your existing build, test, and deployment process.

To check your applications for these problems, try the  free  contrast for Eclipse plugin. It ' s not a simple static analysis tool.  instead, C4E takes advantage of the Java instrumentation API to monitor everything in your application related to SE Curity.  c4e even does full data flow analysis in realtime, so it can trace data from the request through a complex applicati On.  for example, imagine that your code takes a parameter value, base64 decode it, store it on a map, put the map in a D ATA Bean, store The Bean in a session attribute, fetch the bean value in a JSP and insert it into the webpage using EL. Co Ntrast for Eclipse would trace that data and report the XSS vulnerability.  even If you is using complex frameworks and libraries.  no Other tool comes close in terms of the speed, accuracy, and ease of the use.

You can find contrast for eclipse in the Eclipse Marketplace. Then just go to the Servers tab and "Start with contrast"-we ' ll do the rest.

Reference from:

Http://eclipse.dzone.com/articles/10-most-important-security

The most Important Security Controls Missing in Javaee--reference