Sunday, 17 July 2016

Logic Data Modeling (Normalization)

Logic Data Modeling
Able to take a list of data elements and some how applaying various methodology to come up the best data base design.
Where Data Come From?
Order Fine
Order Number:-
Order Date:-
Customer Number:-
Customer Name:-
Customer Address:-
Item Number Item Name Item Quentity Item Price Item Total
Total
Keeping in mind, it is a physical order form, we are going to make a relational database.
These are the process how we are going to convert our form into a relational databse.
Steps:-
  1. Identifay Candidate Key
  2. Select The Primery Key
  3. Apply Normalization
Entity Relational Diagram (ERD)
ERD shows us how our database going to look like.
1. Identifay Candidate Key
Each fields of the order form is known as data element. The question become when we look for a key which one of them is any or how many of them unikly all identify.
Order number would be the cendidate key, because no other order number has the same value.So order number is the primery key.
So definetly you would have confused, if we choose order number is the cendidate key and the same could be the primery key how .
Example:-in politice there are more then one cendidate for election but only one win the game, so it soes not metter , we have more then one cendidate key, but we have to choose out of cendidate one is the primery key.
2. Select The Primery Key
So
3. Apply Normalization
  • 1 NF -- No Repeating Elements, No Repeting Groups
  • 2 NF -- No Partial Dependency on part of the primery Key
  • 3 NF -- No Non Key Attribute dependent on another non key attribute.

A File in logical model is besically called an Entity,Attributes of a particular entity.
Look at out figure order form and find the key and non key attributes.
Remember non key attributes dependent on key attriutes.So what is these keys lets figure out.
Key Attributes Non Key Attributes
Order Number Order Date
Item Num
Item Name
Item Qty
Item Amount
Customer Number
Customer Name
Customer Address
Total Amount
In Normalization we go through a Serious of Questions.
  1. No Repeting elements?
Ans. yes, we have repeting elements.
Going back to the form, find out do we have repeting elements, yes we have , lets how.




Now we have failed First Noramal Form , This is called integrity problem.


 

Remember When ever you fail a Normal Form, You Must Create A new Entity.
This is the methmetical term of Normalization
Remember when ever you create a new entity we must have a primery key.Concentinate primery key means more then one element come together to form a key, New primery key Concentination form the entity That fail, which is order num.
primery key is order_num_item_num
Now item_num is not a non key attribute now it is a primery key. So the dependent elements must come with it.



Now you have two entity.
2 Nd Normal Form ther will be no partial dependency
partial dependency means, which we have a concentinated key which is two pices (order number) + (item number) is it possible the non key attributes is only dependen on one partion of the entity elements.
Lets proof this,
Suppose your order number is 100 and three item number A,B,C you would have one record in the first file_order called order number 100 and you would have three in.
Order Number + Item Number
100 A
100 B
100 C
to be continued...

Programming Methodology

Programming Methodology

Programming Methodology is a Kind of Approch to Solve a given problem. There are three kind of Approch
1.Unstructure
2.Procedure Oriented Programming Language
3.Object Oriented Programming Concepts
1. Unstructure
Is a kind of problem solveing approch in which we use to code the problem directly and if our problem gets increase code also get increase.
Example:-our assembly programming.
Advantage:- Speed writeing code in assemble language, is being directly converted into maching code and it gets execute.
DisAdvantage:-
1.Debugging
2.If we have a bug then we have to debug complet programm, it is not so easy way.
3.No Reuseability
2. Procedure Oriented Programming Language
It follow TOP - DOWN Approch, top down approch means looking a problem in top down angle.
Example:-





Advantage:-
1.Divide the test module wise.
2.Easy to intigrate.
3.Debugging is very easy.
4.Re - Useability
DisAdvantage:-
1.We Concentrating on work not to person who are going to use it (user)
2.We are Concentrating who is doing the work rather then what is being done.
3.Data Security Major Draw Back.
we have only two concept of data in procedure oriented programming.
1. Data can be a global .
2.Data can be Local.
Global variables used by all the functions, Local variables used by only the function in wich we have declered.
lets see sinario in which i want to declare a variable which would be used by.
Do i have a solution.
3. Object Oriented Programming Concepts
It follows Buttom -Up Approch
Example:-Solution for education organisation . It try to look out the problem form the buttom. who are going to use this . Then i will find out the users.
So user of education organisation would be

Who is doing the Task What is the Task
Trainee
Tranee can take a course
Tranee can Write Exam
Tranee can take View Result
Trainer
Set Exam
View Reslts
Admin
Create Trainee
Create Trainer

In this programming methodology we are very much interested in who is doing the task .Then what is the task.
In OOP Methodology what is object?
Object can be anything, accroce what we see now, can be object. It can be a leaving thing and non leaving thing.
Every Object has tow thing:-
1.State OR Attribute
2.Behaviour OR Methods
What is State?
State is something which defines look and feel of object.
What is Behaviour?
What can we do with Object.
Real Time Scinario
Bank Account of a customer
Object is here = customer.
State OR Attribute
what could be the state of a customer.
  • Customer ID
  • Account Number
  • Name
  • Address
  • Balance
Behaviour OR Methods
what can a customer do?
  • Deposit the Amount.
  • Withdraw the Amount
  • Balance Enquery
  • Transfer amount
The States of an object is called as Attribute.The Behaviours of an object is called as methods.
State and Behaviour are together is a Blue Print of a Object And the Blue print of an object is called as Class.
Customer
Raj
Dharmaraj
Bapa
Can we give a customer to directly view or edit customer id, can change account number, can directly update balance, we can not give directly access to state or attribute, can customer deposit amount , can customer withdraw amount, can customer balance enquery, yes customer can do, so we give direct access to behivor to methods.
i should give a restricted access to object by using accesser specifiers. So i keep state or attribute as priate and keep behavior or methods as public.
OOP main mission is to represent real world into the cumputer. there are four features which contribute for representing real world secnaries into the computers.
  • Inheritance
  • Abstratraction\
  • Encapsulation
  • Polymorphism

Software Requirements Specifications(SRS)

Software Requirements Specifications (SRS) 

This article will list eight guidelines that will help you create a well-written SRS that is both complete and unambiguous SRS are created to describe the functional and the non-functional requirements of what should be implemented in the system

1. Use-Cases

Use-case is a term that comes from the object-oriented world. Use-case diagrams depict interactions between actors (users, systems, entities) and functions of a system. A use-case diagram helps you get a high-level view of the system. It is a great starting point before detailed specification requirements are created.

Take a look at the following use-case diagram that describes a use-case and actor interactions for an ATM machine.

The actors of the system are:

1. User
2. ATM Machine
3. Bank
The functions (use-cases) of the system are:
1. Login
2. Get Balance Information
3. Withdraw Cash
4. Transfer Funds
5. Deposit Cash

Notice that use-cases start with a verb.

The use-case diagram above reveals the following facts about this system:

1. Identifies actors and functions of the system
2. Identifies interactions between actors and features of the system
3. Hints at the scope of the system
2. Use-Case Realization
 
Using use-case semantics for deriving functions of the system can greatly benefit you when composing the software requirements specifications (SRS). Use-cases are universally accepted in the software development community and they promote structure and completeness of the SRS.
Once a high-level use-case diagram is completed, a more detailed description of each use-case can start. The exercise of creating a more detailed use-case is also called a "Use-Case Realization." Each use-case contains a sequence of events (steps) that describe its execution flow. Furthermore, each use-case has a number of alternate paths, exceptions, pre-conditions, and post-conditions.

A common structure of a use-case realization consists of the following sections:

1. Name: The name of the use-case
2. Description: A brief explanation of what this use-case is achieving
3. Actors: All participants of the use-case
4. Pre-Conditions: All major events and states of the system that must be present before the use-case can be executed
5. Post-Conditions: All major states that the system assumes after the use-case is executed
6. Successful Path: All steps that fully describe successful execution of the use-case
7. Paths: All steps that describe alternate execution of the use-case (If there are multiple alternate paths or alternate paths are lengthy, you might want to consider creating a separate use-case for it.)
8. Exceptions: All errors that occur during execution of successful and alternate paths
9. Rules: All business rules, computations, regulations, formulas, and constraints of the system
Try to create a simple use-case realization for a "Withdraw Cash" use-case:
1. Name: Withdraw Cash
2. Description: This use-case realizes cash withdrawal use case. First, the client requests cash. If there is enough cash in the client's account, the ATM disperses the specified amount and notifies the client of the new account balance and dispersed amount
3. Actors: Client, ATM, Bank, System
4. Pre-Conditions: Client is logged in
5. Post-Conditions:
a. Cash is dispersed
b. Client's account balance is updated
c. Client is notified of the transaction
6. Successful Path:
a. The client requests cash withdrawal
b. The system establishes a connection with the Bank
c. The system retrieves client's available account types
d. The system displays available account types
e. The client chooses a desired account type
f. The client enters the amount to withdraw
g. The system retrieves the selected account balance from the Bank
h. The system validates available funds against account balance (see computation a in the Rules section below)
i. The system prompts for confirmation
j. The client confirms withdrawal amount
k. The system computes new balance (see computation b in the Rules section below)
l. The system disconnects from the Bank
m. The system disperses specified amount
n. The system prompts that cash is dispersed
o. The system notifies the client of his transaction
7. Alternate Paths: Start from step h in the successful path. The selected account type does not have sufficient funds:
a. The system prompts the client that the withdrawal amount exceeds the account balance
b. The system displays available account types
8. Exceptions:
a. No available account types: The system prompts that "No available account types exit"
b. Requested amount exceeds account balance: The system prompts that "The requested amount exceeds account balance"
9. Rules:
a. Available funds computation: Withdrawal amount must be less than or equal to account balance
b. New balance computation: Deduct withdrawal amount from account balance Look at another use-case realization for the "Login" functionality:
1. Name: Login
2. Description: This use-case realizes the login function of the system. The client inserts a bank card into the ATM card slot and enters his password. If the password is correct, the system logs the client in.
3. Actors: Client, ATM, Bank, System, Bank Card
4. Pre-Conditions: None
5. Post-Conditions: Client is logged in
6. Successful Path:
1. The client inserts his bank card into the ATM card slot
2. The system validates the credit card
3. The system prompts for the client's password
4. The client enters the password
5. The client confirms password entry
6. The system validates the password
7. The system logs the client into the system
7. Alternate Paths: Start from Step 5 in the successful path
a. The system validates the password and the password is incorrect
b. The system increments invalid login count by 1
c. The system notifies the client that the password is incorrect
d. The system prompts for password Exceptions: . Bank card is disabled a. Account is locked b. Bank card is reported stolen c. Password is incorrect
Rules: Client account gets locked out after three unsuccessful login attempts. In the above example, you have listed steps that actors perform to realize a use-case. Now, you can use these use-case realizations to start deriving more precise functional requirements.
3. Structure
Choosing the right structure for your SRS is extremely important. In his book Software Requirements, 2nd edition, Karl E. Wiegers suggests that requirements must be written in a hierarchy. Each level of the hierarchy should drill down to a more specific set of requirements. The hierarchical approach provides several benefits:
� Each requirement is traceable to its parent. You can always trace a child to a parent and vise versa.
� Each requirement can be verified for completeness because because, based on the children, you can verify whether the parent is complete.
The very top parent of your requirements hierarchy is, of course, "Business Requirements." The children of the "Business Requirements" parent are all the high-level use-cases that you show in the use-case diagram. The next level consists of less general requirements, and so on, until requirements can no longer be broken up into more specific requirements. The lowest level of the hierarchy must have requirements that cannot be broken down further.
Create a hierarchy for your ATM system.
1. Business Requirements
1.1 Login
1.1.1 Validate Bank Card
1.1.1.1 Validate for Card Expiration Date Validate that the card's expiration date is later than today's date If card is expired, prompt error message "Card is expired"
1.1.1.2 Validate for Stolen or Lost Card Validate that the card is not reported lost or stolen If card is lost, prompt error message "Card has been reported lost" If card is stolen, prompt error message "Card has been reported stolen"
1.1.1.3 Validate for Disabled Card Validate that the card is not disabled If card is disabled, prompt error message "Card has been disabled as of"
1.1.1.4 Validate for Locked Account Validate that the account is not locked If account is locked, prompt error message "Account is locked"
1.1.2 Validate Password
1.1.2.1 Validate that the password is not blank If password is blank, prompt error message "Please provide password"
1.1.2.2 Validate that the password entered matches the password on file If password does not match, prompt error message "Password is Incorrect"
1.1.3 Lock Account If number of consecutive unsuccessful logins exceeds three attempts, lock account
1.1.4 Maintain Consecutive Unsuccessful Login Counter
1.1.4.1 Increment Login Counter For every consecutive Login attempt, increment logic counter by 1.
1.1.4.2 Reset Login Counter
Reset login counter to 0 after login is successful.
1.2 Get Balance Information
1.2.1 ...
1.2.X ...
1.3 Withdraw Cash
1.3.1 ...
1.3.X ...
1.4 Transfer Funds
1.4.1 ...
1.4.X ...
1.5 Deposit Cash
1.5.1 ...
In the example above, you have fully (at least in the context of this exercise) decomposed the "Login" use-case. If you examine functional requirement 1.1.1.1 (Card Expiration Date), you will find that it cannot be further decomposed; this means that you can no longer break it up into a more specific set of requirements.
Now, look at section 1.1.1 (Validate Bank Card). This section, on its own (without its children), is obviously ambiguous and must be broken down into a more specific set of functional requirements.
The hierarchical structure does not merely help you organize the document better, it also aids in figuring out whether the functional requirements are complete. It is easier to verify whether the "Validate Bank Card" functional requirement is complete if you can review its children instead of looking throughout the whole document for various validation rules.
4. Use Correct Language
You must always use the active voice when writing business requirements. Passive voice adds ambiguity to the document. Here are several examples:
Passive voice: When password and user name are entered, they are validated.
Problems: Who checks for correctness�the user or application? Who enters the password and user name? Active voice: The system validates the user name and password that the user provided.
Passive voice: Notification is sent.
Problems: Who sends the notification�teller, system?
Active voice: The system sends notification to the client.
The SRS must have precise and strong language. You must use words such as must and shall and stay away from such vague words as should, would, user-friendly, effective, usually, slow, fast, and almost always.
Here are several examples:
Incorrect statement: The system usually should respond fast.
Problems: What is the definition of fast�2 seconds or 10 seconds? What does usually mean�50% of the time, or 90% of the time? Correct statement: The system must respond to user requests in two seconds or under for 90% of requests.
Incorrect statement: Because the user almost always requests a hard copy report, the system should provide this capability on demand.
Problems: What does almost always mean?
Correct statement: The system must provide a hard copy report on demand.

5. Keep Technology and Design Out
Why keep technology out of business requirements? It took me a while to agree and comply with this rule. As a technologist, I am tempted to solve the problem, come up with a solution, and design the system. It is important to understand that you, as an author of software requirements specifications, should only concern yourself with WHAT the system must do and not with HOW it will do it. In other words, you must leave implementation decisions to those who will create the technical design specifications. SRS is a document that should be technology free. "The system" (as you call it) happens to be a piece of software that runs on a computer. When composing the SRS, try thinking of "The system" as an entity that has nothing to do with software.
The same goes for designing screens while creating SRS. Even if you have a degree in GUI design and extensive knowledge of "client/system experience," you must refrain from mixing technology (how to do it) with requirements (what is needed).
Remember, SRS describes the functional and non-functional requirements of a system. "A list of available account types" is a requirement, whereas "a dropdown menu of available account types" is an implementation of that requirement.
The following words should not be used in the SRS: Click, dropdown, screen, and checkbox. Instead, use such terms as press, select, and prompt.

6. Make the SRS as Complete as Possible
Incomplete software requirements specifications leave room for ambiguity which leads to more questions later on. Incomplete means "missing information." Sooner or later, somebody must list all validation rules for the "Validate Bank Card" requirement. If SRS is unambiguous, there are fewer questions, fewer assumptions, and therefore less rework later on in the project's lifecycle. You can think of it this way:
An application developer is like a truck driver. The truck driver has to pick up and deliver freight based on a predefined schedule. If the truck driver does not know the schedule, he will set his own schedule and he will improvise.
Furthermore, a complete SRS allows application developers and the quality assurance team to provide more specific estimates. Can anybody give an accurate estimate on how long it will take to develop and unit-test the "Validate Bank Card" functionality? Unless it is decomposed into very specific requirements that can no longer be decomposed, the estimation would be inaccurate. However, once you know that "Validate Bank Card" consists of four specific unambiguous requirements, you can provide a more accurate estimate.
There is another important point: The quality assurance team can start creating test-cases as soon as SRS is complete. The benefit here is two-fold:
1. The QA team can start creating test cases during requirements gathering instead of after application development is complete. This can be done because complete SRS tells you a full story.
2. This is a very useful exercise because it validates whether the SRS is complete and unambiguous and if use-case realizations are correct and make sense.
7. Define the Level of Detail
 
You have already learned that the SRS must be complete and without any ambiguous terms. But what might look ambiguous to one community of readers might not be ambiguous at all to another community. Before you start composing the SRS, get an idea of who will develop your system. Will the development be done by an in-house IT or outsourced to a vendor? If it is done by an in-house IT, the staff is probably familiar with terms used in the SRS (proprietary systems, business terms, abbreviations). If the SRS is to be handed off to a vendor, the content should be as detailed as possible.

Also, keep in mind that your audience consists of stakeholders, developers, QA, and product managers. You must find the common language among all of these groups.
Let me give you a trivial example: Company XYZ has implemented a single sign-on solution called "ComSec." You are working on the SRS that describes a future system that will utilize "ComSec" for all its user authorization and entitlement. Now, you might choose to describe user authentication and entitlement use-case like this: "The system shall use "ComSec" as the means to user authentication and entitlement." Is this enough information to implement this requirement? For somebody who understands "ComSec" it is, but for an outsider it most definitely is not.

8. Get Formal Training
 
Composition of well-written Business Requirements is done via a methodology. This methodology has been studied by many people who have many years of professional experience creating software specification requirements. It is essential that you consult with their expertise either by obtaining formal training or by reading publication on the subject.
SRS documentation is a foundation for all future deliverables�test cases, design specs, and source code. SRS is also an input to such project activities as scope planning and definition, cost estimating and budgeting, human resources planning, and so on. How long does it take to modify or add a business requirement before subsequent phases of the project are initiated? No time at all. Now, imagine adding a new requirement when the project is well underway. Test cases will have to be modified, design specs revised, code re-written, user manuals and training materials updated. Thus, complete, well-written, and unambiguous SRS is a key to a successful project that is on time, on budget, and within the intended scope.
If your organization has been experiencing problems developing application that are on time, on budget, and according to client and stakeholder expectations, it might be wise to introduce some formal training. If formal training cannot be achieved, there are numerous technical books on the market to help you achieve your goals
Conclusion
I hope this article will help you create better Software Specification Requirements. I say this often when I write articles of this sort, but I have to say it again: Knowing the rules is not enough to get you where you want to be. Following these rules is what gets you there.
Another important point is that the above rules are only guidelines and they often need to be broken when there is not enough time or not enough resources to complete a task.

Thursday, 14 July 2016

Bracket orders / Trailing Stop Loss


SL automatically cancelled if target is met and target automatically cancelled if SL is hit. Trailing SL which is optional trails the stoploss price or moves the SL price everytime the scrip moves in a favorable direction by the trailing stoploss value mentioned.

For example, below order to buy Nifty at 8121with a 10 point SL (or 8111) and a 10 point target (or 8131). Trailing SL of 1 point, which means if Nifty goes up by 1 point to 8122, SL automatically changes from 8111 to 8112.


 

Friday, 8 July 2016

SCABBA Vulnerabilities & Solution Approach

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 ( ) 



 public static boolean isNameStringValid(String name)
    {
        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("&lt;script&gt;")
                    && htmlDesc.toLowerCase().trim().contains("&lt;/script&gt;"))
            {
                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();

public List<BoeQstn> getAllQstnSeqId(BoeJobAnlysTmplt myTemId)
    {
        List<BoeQstn> listOfQstnSeqId = new ArrayList<BoeQstn>();
        Session session = null;
        try
        {
            session = createHibernateSession();
            Query query = session
                    .createQuery("from BoeJaTmpltQstn boeJaTmpltQstn  where boeJaTmpltQstn.boeJobAnlysTmplt =:id");
            query.setParameter("id", myTemId);
            listOfQstnSeqId = query.list();

        }
        catch (Exception e)
        {
            e.printStackTrace();
        }
        finally
        {
            if (session != null)
                session.close();
        }
        return listOfQstnSeqId;
    }
 




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.

public void redirectToJATemplatePage() throws IOException
{
      if (loginService.checkAdminAvail(boePrsnMstr.getPrtySeqId()))
        {
             .. .. ..
            //A valid process admin
             .. .. ..
        }
else
        {
           //invalid process admin so logout form the application
            loginMB.logout();

        }
 }
 
 




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.
public boolean isVelidUserForThisPage(BoeUserRole boeUserRole)
    {
        boolean status = false;
        if (checkVelidRole(boeUserRole))
        {
            status = true;
        }
        return status;
    }
 



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.

public class Global
    {
        public static int myTokenSession;

        public static int getMyTokenSession()
        {
            return myTokenSession;
        }

        public static void setMyTokenSession(int myTokenSession)
        {
            Global.myTokenSession = myTokenSession;
        }

    }
 
 








Global global = new Global();

global.setMyTokenSession(“15484154aws8654186sasd548”);
 
 







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