Hello friends👋, A very pleasant day to all😊. This is my first article guys. So I would like to give a short intro about me. I’m a beginner Software Developer, passionate to learn new technologies. I started my career in 2018 and I’m working as a Full Stack Software Developer. #CodingIsLife 💻

It is always fun to share what we learn right? Here I am gonna share my experience when I was working on website security..

When I started my task regarding website security, I just know a little about it.. like Internet is not a safe place and hackers can attack any website any time. So, being secure in the online world becomes more and more important. As I am a beginner, I just think a developer just fixes bugs, writes unit test cases and implements new features. But the most important duty of a developer is to make sure the website or the web application what he/she developed is secure.🔒

To ensure that a web application is secure, you have to identify all security issues and vulnerabilities within the web application itself before a malicious hacker identifies and exploits them.

That is why it is very important that the website vulnerabilities detection process should be done throughout all the Software Development Life Cycle (SDLC) stages, rather than once the web application is live.

Don’t take this light because website clean-up is more expensive💵 than protection

Yes, It’s expensive, indeed. Not just the malware clean-up service itself, but the lost revenue and reputational damage are what can eat up a lot of time and money to recover from.😟

OHHHMYYYGODD…😳

When I googled, I came to know about various vulnerabilities and attacks.. Let me share one of the vulnerabilities which I came across..

Cross Site Scripting (XSS attack)

In simple terms, an attacker attacks by injecting malicious scripts( eg :- JS code) into our website.

Imagine your website has a page http://www.sample.com/test.html that contains the below JavaScript code:

<script>
document.write(“<b>Current URL</b> : “ + document.baseURI);
</script>

So now if an attacker sends HTTP request like http://www.sample.com/test.html#<script>alert(1)</script>, simple enough JavaScript code sent in the URL will get executed, because the page is writing whatever you typed in the URL to the page with document.write function. If you look at the source of the page, you won’t see <script>alert(1)</script> because it’s all happening in the DOM and done by the executed JavaScript code.

And another thing, attacker will not insert scripts like alert(1) to alert you😜, that is just an example which I have given you to understand DOM based attack. Attackers can insert code to steal cookies or sensitive information from the user’s browser. When the attacker has the cookie, they can log into a site as though they were the user and do anything the user can, such as access their credit card details, see contact details, or change passwords.😧

DOM XSS will occur when a source that can be controlled by the user is used in a dangerous sink. In our example the source document.baseURI which includes the malicious script is used in the sink document.write which executes the malicious scripts.

“Prevention is better than cure”

So, the best way to fix DOM based cross-site scripting is to use the right output method (sink). For example if you want to use user input to write in a <div> element don’t use innerHtml, instead use innerText/textContent which operate on the content text of the DOM instead of modifying the DOM structure.

  • Don’t use vulnerable methods like innerHtml, eval, document.write..
  • Sanitise the user input.

These are the ways to remediate DOM based XSS vulnerabilities.

Some Other Tips to make your website secure

Local Storage is not secure

Local storage is a feature of HTML5 that basically allows you (a web developer) to store any information you want in your user’s browser using JavaScript. It persists until explicitly deleted. The data stored will be available for all current and future visits to the site.

Never use local storage to store sensitive information such as session data, user details, credit card info (even temporarily!)

Set HTTP Security headers

You can set security headers to all responses in your application in filter.

Filter is used to intercept request and do some pre-processing. If a request is made for a particular resource such as a servlet, the filter code executes first and then pass the user on to the servlet.

By using filter, we can avoid adding response manually for each of the mapping methods.

SecurityFilter.java

public class SecurityFilter implements Filter {   public void doFilter(ServletRequest request, ServletResponse   response, FilterChain chain)throws IOException, ServletException {
HttpServletRequest req = (HttpServletRequest) request;
HttpServletResponse res = (HttpServletResponse) response;
res.setHeader("Content-Security-Policy","default-src 'self'");
res.setHeader("Strict-Transport-Security", "max-age=31536000; includeSubDomains");
res.setHeader("X-Frame-Options", "DENY");
res.setHeader("X-XSS-Protection", "1; mode=block");


chain.doFilter(req, res);
} @Override
public void init(FilterConfig arg0) throws ServletException {}
@Override
public void destroy() {}
}

Lets take a look into the security headers which are mentioned in the above code:

Content Security Policy (CSP)
The Content Security Policy (CSP) selectively specify which content should be loaded in web applications. This can be done by whitelisting specific origins.

Web browser that supports CSP, such as Chrome or Firefox, parses the header information and determines which sources are trusted or which sources are not trusted based on the instruction sent in the header.

Helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks.

You can see the response headers with content-security-policy

Content-Security-Policy: default-src ‘self’

This policy basically blocks anything that does not load from within the same origin.

Strict-Transport-Security

Set a security header (Strict-Transport-Security) on your web page response. With this security header we can direct our browser to convert all requests to an HTTPS connection

Strict-Transport-Security: max-age=31536000; includeSubDomains

All present and future subdomains will be HTTPS for a max-age of 1 year. This blocks access to pages or sub domains that can only be served over HTTP.

X-Frame-Options

X-Frame-Options :DENY

This header prevents malicious website from framing our pages to render with iframe. Our page will not be embedded into another malicious website’s page within an iframe or any similar HTML elements

X-XSS- Protection

X-XSS- Protection :1; mode= block

A 1;mode=block value enables the XSS filter in browser. If any XSS attacks has been detected, this header blocks the rendering of page.

And there are many other HTTP security headers. If you wanna know more details about the HTTP Security Headers, please visit https://www.netsparker.com/whitepaper-http-security-headers/

Closing thoughts

Okay! Readers, I hope you enjoyed this article and got to know how important is to make your website secure and it is our duty to provide a secure website to our customers.

So.. Hurry up guys! Protect your site from those evil hackers.😈

Thank you friends for spending your time by reading my article. Need your support guys!!!

Happy Reading!!🤗

I’m a Full Stack Developer😎 #PassionateGirl😍💻who is curious to learn new technology.🔍Sometimes silent🤫Sometimes crazy😜 #IceCreamLover😋🍧#CodingIsLife😉