Category: Articles

XSS (Cross-site Scripting) is one of the most common vulnerabilities with a web-application. And, it can be exploited by hackers very easily without using any sophisticated tool.

How does it work?
Most web-applications have forms (text-box etc.) to receive input-data from user. So, a web-application may have a input-text-field to get 'user-id'. The hacker may enter anything in it including "JavaScript". If the hacker enters JavaScript (a malicious code), the server may process it, and then return it. In this case, user-id is not authenticated and it is sent as it is on the error page.

If the user's input data is returned as it is, the java-script code may execute. And, hacker wins!!

I am posting solution for Spring… 

In Spring-MVC, form-tags are used to create jsp page. Spring MVC provides multiple options to encode the html-escape-sequences on server side.

• At global level, it can be defined in web.xml file. This will be applicable to entire application. All form-tags would refer to this definition. The sample code is shown below:

         <context-param>
            <param-name>defaultHtmlEscape</param-name>
            <param-value>true</param-value>
        </context-param>

• At page level, it is defined as a tag-declaration. The code is:

          Any form-tag, after the above declaration uses html-escape-sequence-encoding.

          <spring:htmlEscape defaultHtmlEscape="true" />

• Third option is to define it as attribute for each form-tag. For example, a input-text can be defined as :

          <form:input path="name" htmlEscape="true" />

           Depending upon requirement, it can be implemented as global, page or tag level.

I hope this information helps. Please do post your comments 🙂

Subclipse does not collect or store username and password credentials when defining a repository. This is because the JavaHL and SVNKit client adapters are intelligent enough to prompt you for this information when they need to — including when your password has changed.

You can also allow the adapter to cache this information and a common question is how do you delete this cached information so that you can be prompted again? We have an open request to have an API added to JavaHL so that we could provide a UI to do this. Currently, you have to manually delete the cache. The location of the cache varies based on the client adapter used.

JavaHL caches the information in the same location as the command line client — in the Subversion runtime configuration area. On Windows this is located in %APPDATA%\Subversion\auth. On Linux and OSX it is located in ~/.subversion/auth. Just find and delete the file with the cached information.

SVNKit caches information in the Eclipse keyring. By default this is a file named .keyring that is stored in the root of the Eclipse configuration folder. Both of these values can be overriden with command line options. To clear the cache, you have to delete the file. Eclipse will create a new empty keyring when you restart.

Note: If using tortoise SVN, can reset the same by going to settings > Saved Data and clear Authentication Data.

In need to save XML representation of your Java object Here is a simple 200-line class that will do this using reflection. But don`t worry, there is some very powerful caching going on, so that the performance will be very good.