SCABBA Vulnerabilities & Solution
Approach
1.
Persistent Cross-Site Scripting
2.
SQL injection
3.
Privilege Escalation - Application Design Error (One)
4.
Privilege Escalation - Application Design Error (Two)
5.
Cross site request forgery
Persistent
Cross-Site Scripting
Category - Input Validation:
The input should
never be trusted, so we have implemented strong and positive validation on the
server side in order to ensure that the received information accomplishes what
the application is expecting.
Approach followed:
Validating user
input on server side we have implemented three centralized methods, which is
ensure all received information from the user. In our application we have been
using two kinds of input getaway.
One is Input Text Box and Text Area.
Other one is Input Html Editor.
Recommendations: In both cases you need to avoid blacklisting instead of whitelisting,
because an attacker could send strings in a different encoding and reach a
successful attack.
You could implement something like the code
below:
String validCharacters = "ABC123";
Pattern pattern =
Pattern.compile(validCharacters);
String Fname =
request.getParameter("fname");
Matcher matcher = pattern.matcher(Fname);
boolean matchFound = matcher.matches();
if (matchFound){
//Actions to perform
}
For isNameStringValid(String name) you are not validating any possible XSS, the strings "<script>"
and "</script>"
are not interpreted as XSS
because the browser will parse them as html entities (text) and they are not part
of the html code.
|
isValidHtmlDesc(String htmlDesc)
|
This method is ensuring, all
input Html Editor should not allow any script tags.
Example -- <script>alert(9)</script>
|
|
isNameStringValid(String name)
|
Every input from user is
going through this method, which is responsible to check a valid whitelisted
characters.
Example -- dash - ,
parenthesis ( )
|
{
boolean valid = true;
if (!isEmpty(name))
{
String[] invalidCharacters = { "[", "]", "{", "}", "_", "@", "~", "\\", "|", "<", ">" };
for (int i = 0; i <
invalidCharacters.length; i++)
{
if
(name.trim().contains(invalidCharacters[i]))
{
valid = false;
break;
}
}
}
else
{
valid = false;
}
return valid;
}
public static boolean isValidHtmlDesc(String
htmlDesc)
{
boolean validDesc = true;
if (!isEmpty(htmlDesc))
{
if
(htmlDesc.toLowerCase().trim().contains("<script>")
&&
htmlDesc.toLowerCase().trim().contains("</script>"))
{
validDesc = false;
}
}
return validDesc;
}
SQL
injection
Category: Input Validation
SQL injection attack consists on
the insertion of SQL statement via input data from user to the application.
Approach followed:
We have used Prepared Statement
objects in order to avoid the risk of this type of attacks.
Hibernate parameter binding works
like prepared statements.
Recomantations: It is OK. There are
better practices to implement Hibernate, but it is useful to avoid SQL
injection.
|
Prepared Statements
|
Query q = session.createQuery("from BoeTable boeTable
where boeTable.name =:name");
q.setString(name, "Izi");
Iterator listOfNames = q.iterate();
|
|
Privilege
Escalation - Application Design Error (One)
Category: Access Control
Steps to Reproduce Exploit and Tested in Dev:
1.
UserA Login to the Application as a “Process
Admin”
2.
UserB Login to the Application as another “Process
Admin”
3.
UserA was login as “Process Admin ” and doing
their work in the application.
4.
Just meanwhile, UserB Remove the “Process Admin”
role from one of the UserA
5.
After successful remove Privilege as “Process Admin” from Manage Role for UserA.
6.
Then UserA raise an event or Click on any Page
or Tab which has only available for “Process Admin” role and UserA has now not
a “Process Admin”.
7.
Next he will be redirect to Login Page
automatically.
8.
After
next login of UserA he will found there is no “Process Admin” Role for him.
Recommendations:
I don’t have all the
necessary information but if you are not
implementing a framework that supports roles, as you say you can use a
session parameter that includes the user role
and read it every time a new action is done, CRUD any information. But
you need to be careful if the role of a user is changed during an open session,
because normally the parameters of a userBean such as role are set on login, so
the role needs to be read from the database again to avoid a privilege
escalation.
Approach followed:
We have been adopting above functionality for other roles,
the below is the piece of code which has been implemented for other roles also.
|
Privilege
Escalation - Application Design Error (Two)
Category: Access Control
Steps to Reproduce Exploit:
1.
UserA Login to the application as PEL role.
2.
Then click one Proposal PID, it will forward to
proposal general.
3. All
buttons are enable for this PEL role,
4.
Now UserA copy the URL of proposal general
page.
5.
Then change his role to BOE author.
6.
Pest that copied URL in the address bar and
viewing that Buttons are still enable though he is not a authorized role to
view enable buttons for Proposal General page, but after clicking any button it
will not allow the BOE Author to make any action.
Recommendations: The
same recommendation as above.
Approach followed:
|
isVelidUserForThisPage(userRole)
|
We are going to implement a new method, which is ensure, only valid
user can able to view the page and page must behave according to the users
role.
This method takes a “userRole” parameter which will come from
session.
|
|
Cross
site request forgery
Category: Input Validation.
Approach followed:
Using a difficult token which is
travel with request in addition to session id, after first time user login to
the application , collect the session id and until log out that session id and
token must flow with the request and event raised by the user.
Recommendations: It
is good to use tokens in every action don by the application, with this I mean
that the token has to be included on every form that is sent to the server, so
if the token is not valid the action is not taken. It is better to create a different token from
every time a new form is displayed so the attacker cannot include this token in
his attack.
|
|
1. Create
a Random Method which reatrn a 16 Deisigt Number
In BoeUtil.java File
2. Then
First time when user login to Application and going to set user and role in
session at that time call the Random Method and Session.setAttribute(7847984849879,“tokenKey”);
3. And
send that token key to URL and append with a tokenKey means we r now in
legal.jsp page wiht tokenKey=xxx1
4. Then
i click on Approve Button.
5. Redirect to Welcome Page
Now again Random Method Call and set again to Session.setAttribute(1245874849494794,“tokenKey”);
6. And
append it with URL
No comments:
Post a Comment