What is Web Security?
The web is not safe for every user, Daily we hear about websites becoming unavailable because of denial of service attacks, or displaying changed information on their pages.
These articles are essential for understanding web security basics.
Those articles summarize the most common attacks and explain the countermeasures every web application should implement.
Essentially, these articles provide you with the knowledge needed to create better and safer web applications.
Different Sorts of Web security:
- HTTPS
- TLS
- SSL
- CORS
- CSP
- OWASP (Security Risks) >> I will explain it in part II of this series
-
Hashing Algorithms >> I will explain it in part III of this series
- MD5
- SHA
- scrypt
- bcrypt
Image Source: ccPixs.com
HTTPS
It is the secure version of HTTP, the full name of this protocol is Hypertext transfer protocol secure, which is the primary used to send data between a web browser and a website.
No one else can access the data, Because It uses TLS protocol to encrypt communications, I will explain it at the coming topic.
How HTTPS work?
It uses encryption communication protocol, named Transport Layer Security (TLS), was known as Secure Sockets Layer (SSL).
this encryption uses two keys, one names public key and the other one names private key.
- public key: this shared between the browser and website.
- private key: this key used to decrypt information encrypted by the public key and it not shared out of the server.
Image Source: wikipedia.com
TLS
it is the most protocol in use and designed to facilitate privacy, data security for communications over the internet, the use case of TLS is encrypting the communication between application and servers, emails, messaging voice by use (VoIP).
How TLS work?
Any application or website to use the TLS it must have to install the TLS certification (also known as an “SSL certification”) on the base server, by issued to the person or the organization that own the Domain to install it on the base server.
It contains very important information about the owner, private and public keys to use in decrypt and encrypt the communication.
this process named TLS handshake 🤝 its steps :
- determined the version of the TLS will use during the session.
- Authenticate the identity of the server by using the TLS certificate.
- Generate the Session key for use during the session after the handshake process ended.
This topic needed a farther explanation for this I will make an article about it, and I will add a link to it here.
Image Source: cloudflare.com
SSL
Secure Sockets Layer (SSL), an encryption-based internet security protocol, it was founded for the ensuring of the integrity and privacy of the connections of the internet by the Netscape company at 1995, nowadays it names TLS.
How SSL works?
it like the new TLS based on the concept of the handshake TLS.
What is the difference between TLS and SSL?
SSL is the older version of the TLS, the name changed after the Internet Engineering Task Force (IETF) be the owner of the SSL development after Netscape, some developer nowadays uses the SSL and TLS to referring for the same thing.
Notice Since 1996 SSL not have any new update and this makes it very vulnerability to hacker attacks and all modern browsers no longer support it, they only support TLS.
Image Source: morioh.com
CORS
Cross-Origin Resource Sharing (CORS) is a mechanism that uses HTTP headers to specify which outer origin have access to the local assets and how can access it that is mean we can make a white list for the allowed Cross-Origins that has access to our assets.
the server must have a way to handle the outer requests and this what we will discuss now.
How CORS works?
when the site makes a get request to get resource from the out server, the browser adds a header that contains the origin like the example
Origin: http://www.example.com.The server receives the preflight request and searches in its white-list for Access-Control-Allow-Origins about the giving origin and sends to the browser option call, then the browser will determine if the actual request is safe to send or not, example
Access-Control-Allow-Origin: http://www.example.comor this headerAccess-Control-Allow-Origin: *will allow any request to take the resource.if the server specifies the Methods it will compare the request method with its example
Access-Control-Allow-Methods: PUT, DELETE.
Image Source: keycdn.com
CSP
Content Security Policy is more security layer that helps in detect and mitigate different sort of militias attacks like (Cross-Site Scripting (XSS), data injection attacks, ClickJacking, ETC...).
Cross-Site Scripting (XSS): it a vulnerability that allows the hacker to inject a militias code in the base website and it is for making the client execute it to take sensitive data like cookies, session’s info and site-specific information, That happens because web app does not use enough validation or encoding, The user’s browser cannot detect the malicious script is untrustworthy.
data injection attacks: is a malicious code injected in the network which fetched all the information from the database to the attacker and the number one type of it is the SQL injection.
Click Jacking: or “UI redress attack” is when an attacker tricks a user into clicking on a button or link on another page that uses multiple transparent or opaque layers when he intended to click on the top-level.
How CSP works?
it use Directives concept that’s every Directive have to specify where resources can load from, preventing browsers from loading data from any other locations.
Most used Directives are:
default-src: the default policy for loading (JavaScript, images, CSS, AJAX requests, ETC...) example
default-src ‘self’ cdn.example.com;img-src: defines sources for images example
img-src ‘self’ img.example.com;style-src: defines sources for CSS files example
style-src ‘self’ css.example.com;script-src: defines sources for JavaScript files example
script-src ‘self’ js.example.com;connect-src: defines valid targets for to XMLHttpRequest (AJAX), WebSockets or EventSource, If it makes any connections to a host, that’s not allowed here, the browser will respond with a 400 error example
connect-src ‘self’;Multi-label directives defines:
default-src ‘none’; script-src ‘self’; connect-src ‘self’; img-src ‘self’; style-src ‘self’;
Conclusion:
I hope that I have fulfilled the importance of this topic, and I explained to you the first steps to progress and gain knowledge in this broad field, and I will periodically add any new information on this topic in this series so that all developments in this area kept abreast.
not Forget to read the following supplement from the articles on this topic.
If there is any question, please feel free and contact me or leave it in the comments.
To see similar works and also very important for every developer or knowledge researcher, you can do this by following me on the various social networks 👉 YouTube, Twitter, LinkedIn 👈
Top comments (33)
I don't think its necessary to know about CSP or CORS. You can build a perfectly secure website without any knowledge of these things; most websites I've worked on don't use these security hardening features.
One thing potentially worth mentioning is HSTS which can prevent downgrade attacks.
I disagree.
The fact that CSP is not widely use is a signal that developers - especially frontend devs - should be more educated on security topics.
Without a good Content Security Policy how confident are you that your customers are safe against XSS? For instance, how do you ensure that one of your users doesn't have a browser extension that logs their credentials as they type to a malicious server?
I suggest this article or this other (don't miss the video) from Troy Hunt.
CSP may not be the only option to counter these attacks, but one has to be aware of the risks that can originate from the client-side of our applications and websites.
I agree with you 👌
In practice, it isn't easy to implement CSP when libraries come into play. It is nice to add for hardening, but it isn't necessary, and should not be considered a primary form of defence against XSS.
Nothing about security is easy and the fact that one method is not easy to implement doesn't make it less valuable.
Also, you can always set the CSP as report-only if you're (correctly) worried about potentially breaking stuff. Implementing a good policy slowly over months is better than never doing it at all.
But anyway, if other methods are preferable in your view it's more constructive to explicitly say which ones, so people reading the comments can actually get value out of the discussion.
Cheers!
I consider CSP to be an advanced topic because it is a additional defence against XSS. I do not consider it a "must know". What I consider essential knowledge is how to reason about trusted and untrusted inputs, making sure to sanitize if your framework or library doesn't already do it.
Again, I don't consider this a "must know". I mean, its cool and all but I don't consider auditing something everyone should know about. I'd much rather have people know about ways you can actually completely shoot yourself in the foot than know about CSP.
Surely, although for me they really are different methods solving different but equally serious problems. But this is now more a personal opinion about what is and what is not a must know, so less valuable/interesting.
Thanks for keeping up the thread and replying with an informed opinion and a link to a reputable site.
I really appreciate it 👍👍👍
CORS is pretty important. one instance, we developed a web API, and a client both worked well in local but when moved to stagging env the app was not working reason CORS.
With the modern web, it really became a staple to consume resources from different origins, and understanding why the same-origin policy was introduced makes more sense
Yes, HSTS is useful to understand, I will add it in one of the following articles, but for CSP and CORS it is useful to understand them to increase your knowledge of web security and this knowledge what makes the differences between web developers.
A bunch of things I did not know. Thank you!
I noticed there was a huge sentence fragment here this chunk of your blog post:
I appreciate your help to improve this article, I will edit it now, thanks a lot
Cors is a browser enforced policy.
The server provide the the header during the preflight request made through an OPTION call.
The server does not send any error.
thanks for this information, i will update it and if there other informations in this Topic provide it to us
Cool, very useful info, animus...😁👍✌️
happy to help🤝
I have some feedback. I noticed that you weren't consistent with the acronym for Transport Layer Security. In some places, you wrote TLS, which is correct, while in others you wrote TSL, which is incorrect. You should go back through your article and change any instance of TSL to TLS to make it correct. Thank you.
Thank you for yor note 👌
Please, take note of the following (among others):
All in all, please review the article for possible grammar mistakes.
nice researched article
Thank you
Nice text, but please run a spellchecker before publishing
I will, thanks for the note
So usefull information
I am grateful for your review
Great info, thanks!
it's my pleasure to help you
Some comments have been hidden by the post's author - find out more