I am working on web project on using servlets, filters, jsp, JDBC, etc .
In this, I plan to use common Patterns like
Front Controller, Command, DAO, Abstract Factory, Factory etc.
So far I was able to design the model layer(bo, dao, dto layer).
Now, If the user wants to go the user's home page from a certain page,
the url as of now will be
which when encountered by the controller using the Command Pattern
will instantiate the action
to handle the request.
I feel this action url can be encoded for more security even without using https.
I am aware about the encodeUrl(String) which adds the sessionId to the url.
But is there anything more that can be done to ensure security.
I will appreciate your opinions regarding this.
P.S. Please feel free to elaborate if i need to be more clear about my question.
Madhan Sundararajan Devaki wrote:In my opinion, instead of writing your own Framework (unless you are a Framework developer) you may use the popular frameworks such as Struts2 or Spring etc... to solve your business problems at the earliest. The popular frameworks also offer security and performance.
Thanks for replying,
I agree to your point of "not-trying-to-reinvent-the-wheel",
and although I went through some of the framework codes,
i could not fully understand the flow details.
Here what i am really trying is get the thorough knowledge
by working up from the scratch.
I hope i am not being unreasonable.
Bear Bibeault wrote:You can encrypt values in the URL but not the complete URL. The context path and servlet path must be in clear text. No security issues are introduced by having these paths in clear text.
I got your point.
Upon searching some security issues,
I found something like 'packet-sniffing', 'cross site request forgery', etc.
How can I prevent the requests to from such attacks (which is what I originally meant by improving security, )
Also can you put some light on what is 'Base64' encoding type & why is it used in real-life situations.
The key is to make the "sniffed" data unusable, and that means encrypting the packets themselves. You can't encrypt EVERYTHING, since things like the destination IP address in the packet header have to be readable by network routers. But you can encrypt the payload, and that's the important part.
The easiest way to do that is to employ Transport Layer Security (TLS). When using web protocols, that means using https instead of http. When you do that, the client and server will negotiate the most secure common encryption protocol that they both understand and employ it. This negotiation is transparent, but very important, since periodically someone manages to "break" an encryption technique, and a new scheme must be used instead. Since you don't want to have people scrambling to reset their security framework (or worse yet, rebuild all the webapps), this plug-in approach keeps the whole thing manageable.
BASE64 isn't really encryption, except briefly in the minds of some people at Adobe, perhaps. It's just a very predictable method for rearranging bits.
Pat Farrell wrote:As others have said, just use HTTPS, that's what it was designed for. Its been used in production for well over a decade. Its a solved problem.
Now, if you want to increase system security and reliability, do not ever trust anything coming from the browser.
Got it Pat, Thanks