CYBER SECURITY: Most used keywords

Cyber security

Dealing with security measures is not a day to day thing until your primary business involves around it. It becomes extremely difficult to remember every terms related to security attacks and their standard prevention methods. In this blog, I have tried to capture definitions and small details about major keywords used in cyber security. First section talks about different types of attacks and then preventions . I have also provided links which I found good to get more details about it.

Cyber Security attacks

Malware: The term “malware” encompasses various types of attacks including spyware, viruses, and worms. Malware uses a vulnerability to breach a network when a user clicks a “planted” dangerous link or email attachment, which is used to install malicious software inside the system.

Malware and malicious files inside a computer system can:

  • Deny access to the critical components of the network
  • Obtain information by retrieving data from the hard drive
  • Disrupt the system or even rendering it inoperable

Phishing: Phishing attacks are extremely common and involve sending mass amounts of fraudulent emails to unsuspecting users, disguised as coming from a reliable source. The fraudulent emails often have the appearance of being legitimate, but link the recipient to a malicious file or script designed to grant attackers access to your device to control it or gather recon, install malicious scripts/files, or to extract data such as user information, financial info, and more.

Man in the middle attacks: Occurs when an attacker intercepts a two-party transaction, inserting themselves in the middle. From there, cyber attackers can steal and manipulate data by interrupting traffic. This type of attack usually exploits security vulnerabilities in a network, such as an unsecured public WiFi, to insert themselves between a visitor’s device and the network

Denial-of-Service (DOS) Attack: DOS attacks work by flooding systems, servers, and/or networks with traffic to overload resources and bandwidth. This result is rendering the system unable to process and fulfill legitimate requests. In addition to denial-of-service (DoS) attacks, there are also distributed denial-of-service (DDoS) attacks.

DoS attacks saturate a system’s resources with the goal of impeding response to service requests. On the other hand, a DDoS attack is launched from several infected host machines with the goal of achieving service denial and taking a system offline, thus paving the way for another attack to enter the network/environment.

SQL Injections: This occurs when an attacker inserts malicious code into a server using server query language (SQL) forcing the server to deliver protected information. This type of attack usually involves submitting malicious code into an unprotected website comment or search box. Secure coding practices such as using prepared statements with parameterised queries is an effective way to prevent SQL injections.

Zero-day Exploit: A Zero-day Exploit refers to exploiting a network vulnerability when it is new and recently announced — before a patch is released and/or implemented. Zero-day attackers jump at the disclosed vulnerability in the small window of time where no solution/preventative measures exist.

Password Attack: Password attackers use a myriad of methods to identify an individual password, including using social engineering, gaining access to a password database, testing the network connection to obtain unencrypted passwords, or simply by guessing.

Rootkits: Rootkits are installed inside legitimate software, where they can gain remote control and administration-level access over a system. The attacker then uses the rootkit to steal passwords, keys, credentials, and retrieve critical data.

Cross site request forging(CSRF): A CSRF attack targets Web applications failing to differentiate between valid requests and forged requests controlled by attacker. There are many ways for an attacker to try and exploit the CSRF vulnerability.

This tricks the victim into clicking a URL that contains a maliciously crafted, unauthorised request for a particular Web application. The user’s browser then sends this maliciously crafted request to a targeted Web application. If the user is in an active session with a targeted Web application, the application treats this new request as an authorized request submitted by the user.

To Prevent CSRF CSRF tokens are used. A CSRF token is a unique, secret, unpredictable value that is generated by the server-side application and transmitted to the client in such a way that it is included in a subsequent

https://portswigger.net/web-security/csrf/tokens

Cross site scripting(XSS): Cross-site scripting (XSS) is a security exploit which allows an attacker to inject into a website malicious client-side code. This code is executed by the victims and lets the attackers bypass access controls and impersonate users.

These attacks succeed if the Web app does not employ enough validation or encoding. The user’s browser cannot detect the malicious script is untrustworthy, and so gives it access to any cookies, session tokens, or other sensitive site-specific information, or lets the malicious script rewrite the HTML content. The malicious content often includes JavaScript, but sometimes HTML, Flash, or any other code the browser can execute. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data like cookies or other session information to the attacker, redirecting the victim to a webpage controlled by the attacker, or performing other malicious operations on the user’s machine under the guise of the vulnerable site.

Standards as preventions Measures

JSESSIONID: JSESSIONID is a cookie generated by Servlet containers like Tomcat or Jetty and used for session management in the J2EE web application for HTTP protocol. Since HTTP is a stateless protocol there is no way for Web Server to relate two separate requests coming from the same client and Session management is the process to track user sessions using different session management techniques like Cookies and URL Rewriting. If a Web server is using a cookie for session management it creates and sends JSESSIONID cookie to the client and then the client sends it back to the server in subsequent HTTP requests.

OAuth: OAuth 2.0, which stands for “Open Authorization”, is a standard designed to allow a website or application to access resources hosted by other web apps on behalf of a user. It replaced OAuth 1.0 in 2012 and is now the de facto industry standard for online authorization. OAuth 2.0 provides consented access and restricts actions of what the client app can perform on resources on behalf of the user, without ever sharing the user’s credentials.

Although the web is the main platform for OAuth 2, the specification also describes how to handle this kind of delegated access to other client types (browser-based applications, server-side web applications, native/mobile apps, connected devices, etc.)

https://developer.okta.com/blog/2017/06/21/what-the-heck-is-oauth

Good playground to understand OAUTH: https://developers.google.com/oauthplayground/

SAML: Security Assertion Markup Language (SAML) is an open standard that allows identity providers (IdP) to pass authorization credentials to service providers (SP). What that jargon means is that you can use one set of credentials to log into many different websites. It’s much simpler to manage one login per user than it is to manage separate logins to email, customer relationship management (CRM) software, Active Directory, etc.

SAML enables Single-Sign On (SSO), a term that means users can log in once, and those same credentials can be reused to log into other service providers.

SAML works by passing information about users, logins, and attributes between the identity provider and service providers. Each user logs in once to Single Sign On with the identify provider, and then the identify provider can pass SAML attributes to the service provider when the user attempts to access those services. The service provider requests the authorization and authentication from the identify provider. Since both of those systems speak the same language — SAML — the user only needs to log in once.

Each identity provider and service provider need to agree upon the configuration for SAML. Both ends need to have the exact configuration for the SAML authentication to work.

https://www.varonis.com/blog/what-is-saml/

JSON Web Token (JWT): JWT is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.

When tokens are signed using public/private key pairs, the signature also certifies that only the party holding the private key is the one that signed it.

In its compact form, JSON Web Tokens consist of three parts separated by dots (.), which are:

  • Header: Contains type of token and signing algorithm like RSA, SHA256, HMAC
  • Payload: Contains claims like issuer of token, expiration time, subject and other information.
  • Signature: To create the signature part you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that.

Therefore, a JWT typically looks like the following.

xxxxx.yyyyy.zzzzz

More information at: https://jwt.io/introduction

Hyper text transfer protocol(HTTPS): Below diagram defines it very well.

HTTPS established an encrypted link between the browser and the web server using the Secure Socket Layer (SSL) or Transport Layer Security (TLS) protocols. TLS is the new version of SSL.

https://www.tutorialsteacher.com/https/what-is-https

Secure socket layer(SSL): SSL provides a secure channel between two machines or devices operating over the internet or an internal network. This turns a website’s address from HTTP to HTTPS, the ‘S’ standing for ‘secure’. SSL is the predecessor to the modern TLS encryption used today.

Before SSL data transferred over internet was in plain text which can be misused by hackers. SSL was created to protect user privacy. By encrypting any data that goes between a user and a web server, SSL ensures that anyone who intercepts the data can only see a scrambled mess of characters. The consumer’s credit card number is now safe, only visible to the shopping website where they entered it.

SSL can only be implemented by websites that have an SSL certificate (technically a “TLS certificate”). An SSL certificate is like an ID card or a badge that proves someone is who they say they are.

One of the most important pieces of information in an SSL certificate is the website’s public key. The public key makes encryption possible. A user’s device views the public key and uses it to establish secure encryption keys with the web server. Meanwhile the web server also has a private key that is kept secret; the private key decrypts data encrypted with the public key.

https://www.kaspersky.com/resource-center/definitions/what-is-a-ssl-certificate

Certificates Authorities: A certificate authority (CA) is a trusted organisation that issues digital certificates for websites and other entities. CAs validate a website domain and, depending on the type of certificate, the ownership of the website, and then issue TLS/SSL certificates that are trusted by web browsers like Chrome, Safari and Firefox.

https://www.digicert.com/blog/what-is-a-certificate-authority

Cross-origin resource sharing(CORS): When you want to get a public resource from a different origin, the resource-providing server needs to tell the browser “This origin where the request is coming from can access my resource”. The browser remembers that and allows cross-origin resource sharing. It happens in 3 steps:

  1. When the browser is making a cross-origin request, the browser adds an Origin header with the current origin (scheme, host, and port).
  2. On the server side, when a server sees this header, and wants to allow access, it needs to add an Access-Control-Allow-Origin header to the response specifying the requesting origin (or *to allow any origin.)
  3. When the browser sees this response with an appropriate Access-Control-Allow-Originheader, the browser allows the response data to be shared with the client site.

https://web.dev/cross-origin-resource-sharing/

If you think there are more terms which should be included, please add in comments section so I can include those as well.

Deepti Mittal working as software engineer for past 14 years. Right now she is working with Thoughtworks based out of Bangalore.