Security - atabegruslan/Notes GitHub Wiki

Security

Preliminary knowledge

Cryptography: https://github.com/atabegruslan/Notes/wiki/Cryptography

SSL & TLS

TLS is a bit better than SSL.
SSL is by port - secure connection used from the get-go.
TLS is by protocol - these connections first begin with an insecure "hello" to the server
and only then switch to secured communication after the handshake between the client and server is successful.
If this shandshake fails for any reason, the connection is severed.

SSL/TLS uses both asymmetric and symmetric encryption. Asymmetric encryption is used to establish a secure session between a client and a server, and symmetric encryption is used to exchange data within the secured session.

https://www.youtube.com/watch?v=iQsKdtjwtYI

https://www.youtube.com/watch?v=niLaNbOsn28

https://github.com/atabegruslan/Notes/blob/main/notes/security/ssl_tls_details.pdf

HTTPS

https://www.youtube.com/watch?v=j9QmMEWmcfo

Having HTTPS on your server

Below is what it looks like after you got the certificate

PEM: The default format for storing keys. Can have extensions of .pem, .crt or .key. They can be encoded in base64.
X.509: The standard for defining those formats. It is also used for SSL certificates.

SSH

SSH2 breaks SSH1 down into: Transport Layer, Connection & Authentication Protocols.

Differences:

  • Session symmetrical key goes from client to server via Diffie-Hellman method, not encrypted using server key.
  • CA will sign the public keys used in the communication. (same procedure as in SSL)
  • SSH1 enforce integrity via CRC, SSH2 uses message authentication codes, eg: hmac-md5, hmac-sha1, hmac-ripemd160.
  • No Rhosts support in SSH2.
  • SSH1 only allows negotiation of the symmetric encryption algorithm, all other things are hard coded (mac, compression etc).
  • SSH2 server can dictate the client to use multiple authentication methods in a single session to succeed. However SSH1 only support one method per session.
  • SSH2 allows the change of session key periodically.

https://www.slashroot.in/secure-shell-how-does-ssh-work

Below is what it looks after immediately after creating SSH keys:

SSH Tunneling

http://chamibuddhika.wordpress.com/2012/03/21/ssh-tunnelling-explained/

Remote Access

https://www.techotopia.com/index.php/Configuring_CentOS_Remote_Access_using_SSH

Kerberos

Auth and related security issues

Auth techniques: https://github.com/atabegruslan/Notes/wiki/Auth

Simple common-sense things you can do

Below is how you can have a symmetric encryption on credentials when sending them over APIs

Below is how you can hide secrets in the proxy

Attacks:

SQL Injection

Injection of malicious SQL code. Use PDO or any modern framework to sanitize any malicious SQL code into mere text.

XSS

Injection of malicious JS code. Sanitize user input. Especially escape all the <script> tags.

XXE

Directory traversal attack & File inclusion vulnerability & Remote code execution

Clickjacking

Timing attack

Replay attack

Eg: Call the request to deposit money into my account multiple times.

On a similar topic: Use this POST and Redirect pattern to avoid multiple submits when user clicks the submit button too many times: https://en.wikipedia.org/wiki/Post/Redirect/Get

Cookie Poisoning

Stealing your password

DDoS

2 Solutions

  1. If that's random attack, happen sometimes, we need to have a good firewall standing at or before balancing layer, so our core processor won't be affected by the attack. This solution base on the situation so we can have different methods: Manual built firewall (nginx/lua), 3rd-party firewall, or even using IDS

  2. If that's a targeted attack, and we know who/what is doing that, we can still using firewall to stay away from issue with our core processor. But apart from that, in order to not loosing resources just to check and ignore in specific conditions, we can even do an attack, back to the attacker, by using very basic methods (like SYNC/ACK flooding), so we can just spending a very small resource to make attacker "shut their mouth"

Header security

Q: Are HTTPS headers encrypted?
A: Everything are encrypted (Header and Body).

That's why SSL on vhosts doesn't work too well - you need a dedicated IP address because the Host header is encrypted.

The Server Name Identification (SNI) standard means that the hostname may not be encrypted if you're using TLS.
Also, whether you're using SNI or not, the TCP and IP headers are never encrypted. (If they were, your packets would not be routable)

Protect Response Headers: https://scotthelme.co.uk/hardening-your-http-response-headers/

Defending Against Web Attacks:

HTTP header security: https://www.contextis.com/en/blog/security-http-headers

Use headers:

  • Content-Security-Policy : define a whitelist of approved sources of content for your site (eg css & js ...)
  • Strict-Transport-Security : force https usage
  • Public-Key-Pins : providing a whitelist of cryptographic identities that the browser should trust. only ever accept a specific set of certificates
  • !X-Frame-Options : stop attacker forging your site via iframe. against click jacking
  • !X-Xss-Protection : dont execute unescaped malicious(xss) input
  • X-Content-Type-Options : prevents browser from trying to mime-sniff the content type of a response

Remove headers:

  • Server : not reveal server software
  • X-Powered-By : not reveal web technology

Secure cookies:

Cookie attributes

https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/02-Testing_for_Cookies_Attributes

Secure

Secure channel (eg: HTTPS) only

HttpOnly

Can NOT be accessed by client-side JS. Limits XSS

SameSite

Affects CSRF

https://www.youtube.com/watch?v=aUF2QCEudPo

strict:

  • Cookie isn't sent when you click a link to the website from another website.
  • Cookie isn't sent when requested from eg an img src

lax

  • Cookie is sent when you click a link to the website from another website.
  • Cookie isn't sent when requested from eg an img src

none

  • Cookie is sent when you click a link to the website from another website.
  • Cookie is sent when requested from eg an img src
  • Vulnerable to CSRF

Example

SetCookie: PHPSESSID=36cb82e1d98853f8e250d89be857a0d3; path=/; HttpOnly; secure

  • HttpOnly attribute on setcookie header : disable the ability to read cookies using external JavaScript.
  • secure attribute on setcookie header : forces your application to send cookies only over HTTPS.
  • Killing the session upon closing the browser.

Consider this scenario

A user may view an authenticated page, log out,
and then a malicious user can use the browser history to view the cached page.

Mitigation:

Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0

Referrer-Policy: same-origin

  • Referrer Policy is a mechanism that web applications can leverage to manage the referrer field, which contains the last page the user was on.
  • The Referrer-Policy response header instructs the browser to let the destination knows the source where the user was previously.

CSRF, SOP & CORS

Cross Site Request Forgery

This is a subtype of a larger category of attacks

  • Privledge escalation
    • Confused deputy attack
      • CSRF

Articles:

Same Origin Policy

You can't receive resources from a different origin.

Applies to XMLHttpRequest and fetch.
Postman doesn't care about SOP, it's a dev tool not a browser.

Cross Origin Resource Sharing

For requests to a different origin:

  • Safe method: GET, POST or HEAD
  • Safe headers – the only allowed custom headers are:
    • Accept,
    • Accept-Language,
    • Content-Language,
    • Content-Type with the value application/x-www-form-urlencoded, multipart/form-data or text/plain.

Any others cause a "pre-flight" request to be issued in CORS supported browsers.

JQuery quirk

CORS POST request works from plain javascript, but not with jQuery:

jQuery 1.5.1 adds "Access-Control-Request-Headers: x-requested-with" header to all CORS requests.

jQuery 1.5.2 does not do this.

Setting a server response header to "Access-Control-Allow-Headers: *" doesn’t solve the problem.

Need “Access-Control-Allow-Headers: x-requested-with” specifically.

Flash Exploit

Scenario:

Server expects JSON POST body. These are a bit harder to exploit because:

  • Harder to craft using form inputs
  • Setting custom headers requires AJAX which will fire an OPTIONS pre-flight request But still, if content-type header is ignored by server, then:
  • We can craft JSON body using form inputs
  • We can use AJAX to make and send the JSON (Response may be blocked by SOP, but the attack request will still make it to the server) But if content-type header is explicit, ie: server expects the request's content-type header to be application/json, then
  • We can no longer exploit using form inputs. But if the server allows your browser to set the content-type header (ie: Access-Control-Allow-Headers:Content-Type)
  • We can still exploit via AJAX But if the server don't have Access-Control-Allow-Headers:Content-Type, then we'll have to use the Flash exploit:
  • Flash isn't affected by SOP. It operates on its own rules.
  • So we use ActionScript to make the request with a forged content-type header. But Flash will not make a request to a different origin with custom headers unless the server have crossdomain.xml. So if the crossdomain.xml isn't there, then:
  • We send the Flash request to another file on the same server as the Flash file.
  • This file will do a 307 redirect (307 redirects without changing the headers).
  • The HTTP 307 will redirect the POST body and the headers to the victim.

References:

Related things

JQuery AJAX:

crossDomain (default: false for same-domain requests, true for cross-domain requests)
Type: Boolean
If you wish to force a crossDomain request (such as JSONP) on the same domain, set the value of crossDomain to true. This allows, for example, server-side redirection to another domain. (version added: 1.5)

https://stackoverflow.com/questions/21255194/usages-of-jquerys-ajax-crossdomain-property/32296615

headers (default: {})
Type: PlainObject
An object of additional header key/value pairs to send along with requests using the XMLHttpRequest transport. The header X-Requested-With: XMLHttpRequest is always added, but its default XMLHttpRequest value can be changed here. Values in the headers setting can also be overwritten from within the beforeSend function. (version added: 1.5)

X-Requested-With: XMLHttpRequest means indicates that the request was made by XMLHttpRequest instead of being triggered by clicking a regular hyperlink or form submit button.

Overcome CORS blockages

Headers in server

In server, add Access-Control-Allow-Origin: * to response headers.

JSONP

Example:

<script>
function getCountries(data) 
{
  window.countries = data;
}
</script>
<script src="https://ruslan-website.com/misc/autosugg/autosugg.php?callback=getCountries"></script>
var countries = JSON.parse(window.countries);
$countries = $sth->fetchAll(PDO::FETCH_COLUMN, 0);
$countries = implode($countries, '","');
$countries = '["' . $countries . '"]';

echo $_GET['callback']."(".json_encode($countries).");";

Full Example: https://gist.github.com/atabegruslan/b67cb2d871c8efc49b42bc56e40bd4b2

Proxy

Public Proxy

Own Proxy

CORS browser plugin

For every request, it will add the Access-Control-Allow-Origin: * header to the response.

Content Security Policy

⚠️ **GitHub.com Fallback** ⚠️