Overcome duplicate form submission in Struts

There are three parts of any struts code which we use for validation of user fields:

1) Form Bean

2) Form Action

3) Submit Action

With appropriate use of tokens in these classes we can avoid duplicate form submission, a vector for Cross Site Request Forgery (CSRF of XSRF).

Where to use:
1) Inside Form Bean:
   Right after instantiating Action Error inside Validate() method write below lines:

   String token =request.getParameter("org.apache.struts.taglib.html.TOKEN");
    if(isToken!==null)
        {
              //write your validation code here
         }
2) Inside Form Action:
    Right after instantiating FormBean, put below line:
         saveToken(request);

3) Now, the turn of Submit Action:
     isTokenValid(request)
        {
           //Write all your valitaion code here
        }
    Close the loop and put a suitable redirect in case validation fails.

4) The knotty stuffs needed now
 > Make entry for redirection in struts.config file in case the validation fails.
 > Create a jsp with error message and make entry of this jsp in tiles.xml.
    One simple example of error.jsp:
    Unable to access the page you are looking.

crossdomain.xml, the vulnerable gateway

What is crossdomain.xml?

The crossdomain.xml file is a cross-domain policy file. It grants the Flash Player permission to talk to  servers other than the one it's hosted on. A simple example:

If your website is hosted at www.xyz.com, your crossdomain file

should look like:

 

<?xml version="1.0"?>

<cross-domain-policy>

       <allow-access-from domain="*.xyz.com" />

</cross-domain-policy>

or

<?xml version="1.0"?>

<cross-domain-policy>

    <allow-access-from domain="www.xyz.com" />    

    <allow-access-from domain="xyz.com" />

 </cross-domain-policy>

If you wanted to allow abc.org to use your server as host, add one more line like:

           <allow-access-from domain="*.xyz.com" />    

But if your file is like:

<?xml version="1.0"?>

<cross-domain-policy>

    <allow-access-from domain="*" />

</cross-domain-policy>

It is a security threat. It exposes the domain hosting. Attackers cannot only forge requests, they can read responses as well.

Where can you find this?

It is present at the root directory of host. It can be viewed like:

https://www.xyz.com/crossdomain.xml.

And the journey continues.................

Whenever you change a place, a lot of stuff changes..........here comes the most significant role of life "Adaptability....", yes the meaning of this word changes per capita. Someone calls it compromise, someone calls it flexibility, but I refer it as "adaptability".

What is your definition for it?

I define it as extension of your comfort/discomfort zone beyond your familiarity. The best way to understand it is the change in the food and communicational aspects.

I am proceeding along with my journey:

I belong to eastern part of India; yes the fluent and the legacy speaker of Hindi. I started my away home stay from the western part of India. Though the language and food habits did not change a lot but culture and climate changed (this time unbearable hot). I was pushed to a bit away from my comfort zone I was having with since my birth. 

Then, came the northern part of India; undoubtedly cooler than ever before. Again the adaptability was challenged and the comfort zone was twisted a bit more but yes, it brought up a bit more social familiarity. 

Finally, came the acid change of my life, when I shifted to Bangalore, the Silicon Valley of India. Here came the big challenge of survival in terms of food and communication, termed as the mandate of survival. Adaptability was drastically twisted and for some unexpectedly long time it was changed to compromise. Head became tail and tail became head. But it coined a new turnaround of my life, we call as "in-dependency", yes I am referring to economical in-dependency, the ultimate maturity. In-dependency, uffff....... came at the cost of compromise.  But slowly when the realization of in-dependency began to visualize.....compromise became adaptability. 

And the journey continues.................

Test vs Validation………..

As a software developer, I belong to the world of micro and nano reactions and observations, as we (Software engineers) create to and fro reactions (definitely by this I mean software functionality, i.e. users' request and applications' response).

During my development career, every day before I go through the words "test" and "validate"  once ready with deliverables. 

What are these actually? Simply literary words or do they carry weight?

My answers: yes, they do.

Description:

Whenever I create or make changes pertaining to application, I do a cat eye observation of it. I am saying like this because by that time, I know I am the expert who knows the application’s behavior and flow. It may be code wise or UI wise but yes, I know. That's why, what I do, I term it as "validation". 

But when it comes to normal user, they don't care how it should happen? They wary of how is it behaving? They don't bother about what's the flow; they worry about is it good? Is it comfortable? Is it posing any threat to my information? For the sake of these doubts, they do a round-around of the application. In my opinion, what they do is what we call "testing". They test the application, they test their comfort with the application, and they test their doubts and try to clarify them.