What is the impact and threat of Spectre in Javascript? If you have looked into this demo of Spectre in JavaScript: Did I get it right that only current site memory can be accessed, due to site isolation etc? I saw there is also an addon to detect attackts (Spectroscope). Can somebody describe the potential impact of it? If I visit a site attacking me via Spectre and they can only get that site info (site isolation) what is the threat?

That is an incorrect assumption. Right from the Meltdown/Spectre website:

Spectre breaks the isolation between different applications. It allows
an attacker to trick error-free programs, which follow best practices,
into leaking their secrets.

A vulnerability in the CPU architecture (this is not a browser vulnerability) is not aware of or limited by arbitrary boundaries such as site isolation, as it is at a much lower level. Memory of other processes can be read, or even from the kernel. It is a major violation of the process isolation-based security model that many things rely on.
For more information, I recommend reading the above linked website, and the research paper. There are also plenty of ELI5 posts out there if that's too deep.


How to generate ec256 private public key in hex format Could someone tell me how to generate key pair like this in hex format:
This is from SampleCode/RemoteAttestation/service_provider/service_provider.cpp from the repository: https://github.com/intel/linux-sgx/tree/master/SampleCode/RemoteAttestation

// This is the private EC key of SP, the corresponding public EC key is
// hard coded in isv_enclave. It is based on NIST P-256 curve.
    static const sample_ec256_private_t g_sp_priv_key = {
        {
            0x90, 0xe7, 0x6c, 0xbb, 0x2d, 0x52, 0xa1, 0xce,
            0x3b, 0x66, 0xde, 0x11, 0x43, 0x9c, 0x87, 0xec,
            0x1f, 0x86, 0x6a, 0x3b, 0x65, 0xb6, 0xae, 0xea,
            0xad, 0x57, 0x34, 0x53, 0xd1, 0x03, 0x8c, 0x01
        }
    };

// This is the public EC key of SP, this key is hard coded in isv_enclave.
// It is based on NIST P-256 curve. Not used in the SP code.
static const sample_ec_pub_t g_sp_pub_key = {
    {
        0x72, 0x12, 0x8a, 0x7a, 0x17, 0x52, 0x6e, 0xbf,
        0x85, 0xd0, 0x3a, 0x62, 0x37, 0x30, 0xae, 0xad,
        0x3e, 0x3d, 0xaa, 0xee, 0x9c, 0x60, 0x73, 0x1d,
        0xb0, 0x5b, 0xe8, 0x62, 0x1c, 0x4b, 0xeb, 0x38
    },
    {
        0xd4, 0x81, 0x40, 0xd9, 0x50, 0xe2, 0x57, 0x7b,
        0x26, 0xee, 0xb7, 0x41, 0xe7, 0xc6, 0x14, 0xe2,
        0x24, 0xb7, 0xbd, 0xc9, 0x03, 0xf2, 0x9a, 0x28,
        0xa8, 0x3c, 0xc8, 0x10, 0x11, 0x14, 0x5e, 0x06
    }
};

I am new to cryptography. The definition of the data type:

#define SAMPLE_ECP256_KEY_SIZE             32
typedef struct sample_ec256_private_t
{
    uint8_t r[SAMPLE_ECP256_KEY_SIZE];
} sample_ec256_private_t;

typedef struct sample_ec_pub_t
{
    uint8_t gx[SAMPLE_ECP_KEY_SIZE];
    uint8_t gy[SAMPLE_ECP_KEY_SIZE];
} sample_ec_pub_t;

 #define SAMPLE_FEBITSIZE                    256
#define SAMPLE_ECP_KEY_SIZE                     (SAMPLE_FEBITSIZE/8)

This is using the NIST P-256 curve aka secp256r1 (RFC 4492) aka prime256v1.

You can create key pairs and print them in hex format using OpenSSL, e.g.

$ openssl ecparam -name secp256r1 -genkey | openssl ec -text -noout
using curve name prime256v1 instead of secp256r1
read EC key
Private-Key: (256 bit)
priv:
    2c:23:47:d5:a6:a2:9e:32:28:ae:7b:8d:7b:a2:67:
    87:eb:e6:57:e0:51:76:59:1a:6b:f8:a7:17:9b:d3:
    b9:18
pub:
    04:ab:e6:db:26:cc:b7:4c:d0:03:24:52:8e:96:33:
    50:19:21:ce:50:c5:34:b5:57:b7:bc:ac:63:d1:eb:
    06:e4:53:76:95:46:39:d2:54:38:e0:a7:52:3c:00:
    fe:0a:66:1d:10:cd:ed:ed:75:b5:72:50:e8:ee:17:
    99:d0:39:62:b6
ASN1 OID: prime256v1
NIST CURVE: P-256

Of course they are not in such a beautiful 4x8 alignment, but easy enough to replace : with , 0x

2c, 0x23, 0x47, 0xd5, 0xa6, 0xa2, 0x9e, 0x32, 0x28, 0xae, 0x7b, 0x8d, 0x7b, 0xa2, 0x67, 0x
87, 0xeb, 0xe6, 0x57, 0xe0, 0x51, 0x76, 0x59, 0x1a, 0x6b, 0xf8, 0xa7, 0x17, 0x9b, 0xd3, 0x
b9, 0x18

and then do the rest manually, if you use this hard coded into your program:

    {
        0x2c, 0x23, 0x47, 0xd5, 0xa6, 0xa2, 0x9e, 0x32,
        0x28, 0xae, 0x7b, 0x8d, 0x7b, 0xa2, 0x67, 0x87,
        0xeb, 0xe6, 0x57, 0xe0, 0x51, 0x76, 0x59, 0x1a,
        0x6b, 0xf8, 0xa7, 0x17, 0x9b, 0xd3, 0xb9, 0x18
    }


Is it particularly unsafe to use openvpn or pptp with only username/password authentication instead of certificates? I use a vpn server (supporting pptp and openvpn) built in to my router at home to make a secure connection back to my home network. I currently use OpenVPN with certificate authentication, but since my router only distributes the keys in the form of a .ovpn file and not with individual files, it is difficult to use with Linux laptops that can't properly read the ovpn file.

So anyway, for convenience I was thinking about moving to username and password authentication instead. I'm not concerned with anyone making a serious effort to see what I'm doing - my intention is simply to hide my traffic while on publicly accessible networks, while at the same time being able to access resources on my home network. If my VPN thwarts the average script kiddie sitting on the same network as me, I'm satisfied with its security.

So, given that I use a strong password and the router has properly implemented its VPN server, will my traffic be secure enough for my needs?

Short answer: Is not unsafe.

Long answer:

The option of using a certificate or password to authenticate the client does not change the traffic encryption. It's only used in the first stage of the VPN connection. The server and client will negotiate the session keys only after authenticating the user, independent of the use of certificate or password.

If your password is strong enough, the average script kiddie will be not able to snoop on your traffic. Maybe it can even resist some advanced ones.


Drill a (physical) hole on a g10 openpgp smart card I have a g10 smart card (http://g10code.com/p-card.html)

I want to make a hole on it, so I can pass a cord on it and hopefully remember to bring it with me. would I kill the card if I drill a hole on it? I have in mind something like this:

This wouldn't be a problem at all. As you see in the picture in your link, there is a version with a smaller form factor (ID-000). This is the same card just with cut outs.
Everything outside the contact area is just plastic. I made you a drawing in paint showing where the actual IC is in the card. Everything outside this box can be removed without any problem.

(copyright of the picture: g10 Code GmbH, I stole it from their webpage. My modification (red square) is released as CC-0)

If you have a strong flashlight (you should have one, they are awesome) you can use it to "see through" the card to check that. That can also be used to see the antenna on RFID cards for example (where drilling holes can be a problem)


How to support secure creation of a user account over an external API via a queued job? So this question is delving into security and encryption and the problem potentially hasn't been encountered by many. Answers may be theoretical. Let me outline the scenario...

A website frontend is driven via a backend API. The backend has an endpoint handling a generic registration form with username and password. It's using SSL.
The backend API handles registration via an async job queue. The queue does not return responses to the API server. It's a set and forget operation to queue up the registration.
Queued jobs are picked up by workers. The workers take care of creating the user account. These workers need access to the plaintext user password so that they can trigger a third-party API registration call with the password.

So the real crux of the problem is the syncing of the password to the third party API while not revealing it to prying eyes. The queue poses the problem of not having direct access to the plaintext password from global POST data anymore, meaning it needs to be stored in some fashion in the queue.

The queue can easily store the hashed password and copy it directly to the users table. This solution does not allow for syncing of the password with the third party API, however, as it's already encrypted. I toyed with two-way encryption, but am whole-heartedly concerned with leaving the password prone to decryption by an attacker.

Can anybody think of a secure way to handle this scenario of password syncing?

The queue is a requirement and it's assumed that this is readable by anyone with access to the server. The passwords don't necessarily have to be synced; the password for the third-party API could be a derivation of the original so long as there's a secure means to decrypt via the logged in user without supplying their password. This is essentially to simulate Single Sign-On with a third party API that does not support SSO.

This appears to break down to simply;

I have a job queue containing plaintext passwords.
I would like to prevent other server users from accessing those passwords.

This seems like it should be quite easy, assuming 'other server users' does not mean a superuser account.

What you need to do is engineer it so that your frontend <-> jobqueue link acts as a diode, jobs are able to go in, but no data can egress from the jobqueue in the direction of the front end.

Some simple examples;

The job queue exists in a database to which the front-end does not have access. The data is encrypted under a key generated at run-time.
The job queue exists only in RAM in a process marked as untracable (in Linux you will need AppArmor and I believe this is possible by removing the capability CAP_SYS_PTRACE)
The job queue does not exist - make the back-end calls synchronous.

That said, doing anything other than immediately hashing plaintext passwords is antipattern imho.


Protecting  in Django In my Django template, I have a link like this:

<a href='{{ my_model.some_url }}'>

The some_url bit is a Django URLField that a user can influence.

Can this be exploited in any way? (What comes to mind is including a quote in the URL and then arbitrary HTML.)

What can I do to protect this code?

In general there are valid URL schemes that are dangerous. Most obviously javascript:, which as a pseudo-URL refers not to a new location, but to a command to execute on the current page. Allowing a javascript: URL to be added to your page means you have a cross-site scripting problem.

There are also other scripting aliases (vbscript:, mocha: et al), as well as data: and any number of arbitrary protocol handlers that third-party software might have installed at the client. So typically you need to whitelist URL schemes.

Django's default URLValidator for URLField does this, allowing only http, https, ftp and ftps links, so as long as you haven't replaced the validators it should be OK. (You may wish to do so, if that's not the set of schemes you want.) If you have any other means to populate the some_url field that doesn't go through the normal field/validator then you'll need to make sure that is validated too.

  (What comes to mind is including a quote in the URL and then arbitrary HTML.)

As long as you haven't disabled autoescape, the default HTML-escaping provided by {{...}} templating prevents that (it correctly encodes single quotes to &#39;).


Why would an attacker authenticate to my Google Search Console? Someone uploaded (I don't know how how but I think via my Wordpress which was outdated for just a day...) a Google Search Console authentication to my server. I just realized this because Google Search Console sent me a mail about a new authentication to a script-generated email account (many numbers and characters as username).

What could be the potential purpose of such an attempt? I can't imagine anything besides maybe spam activities or something.

Note: I am not very deep into IT security in general, besides common sense and what I learned in my years of software development.

If they were able to authenticate to Google Search Console, it means they had, at least for some time, control of your website.

If the hacker were any good, they would've immediately setup an alternative access to get back into your site (perhaps a backdoor of sorts, preferably not easily detectable).

I have seen at least once instance where the hackers took control of a website, posted viagra ads, uploaded click-fraud code and even hosted malware for some time on the site. For that period, they used blackhat SEO techniques to promote the site (specifically the links they wanted) - which was how the Dentist (the victim) found out about the hack in the first place. A friend asked him why his site is in search results for the oddest things.

But almost everyone knows that Google will notify the site owner when a new email is added to site management - so in your case it doesn't make complete sense, but hopefully my answer will give you something to start with.

PS: You should look for what else the hacker could've done while (s)he was in control - especially alternative ways they can keep getting back in. If you have a way of logging events remotely, that's a great thing to do, even if it is a tad late now. You will come to know what the hacker is doing on your site if/when they return.

PPS: My product ActiFend was made for a different purpose, but it can do remote logging + we have security analytics dashboards internally; so if you are unable to make progress, let me know (through the app or just write to support at actifend dot come) and I'll see we can use our chops to find any elusive needle for you. This is just out of my curiosity, so no purchase needed. :)


Are The ca Policy Values In the OpenSSL Configuration File Applied When Both Creating AND Signing Certificates? Are the 'ca' policy values that are present in the OpenSSL configuration file applied when the 'ca' command is used to create a certificate AND when the 'ca' command is used to sign an existing certificate?  For example, suppose the following policy section is present in an OpenSSL configuration file:
[ policy_basic ]
commonName                  = supplied
organizationName            = match
organizationalUnitName      = supplied
streetAddress               = optional
localityName                = match
stateOrProvinceName         = match
countryName                 = match
postalCode                  = optional
emailAddress                = optional

If I used the 'ca' command to generate a Certificate Signing Request ("CSR"), and no values were supplied for the "optional" policy fields, would the CSR's Subject Name Relative Distinguished Names ("RDN") contain the following:
commonName                  = Whatever I entered at the prompt or was stipulated as the default
organizationName            = The issuing CA certificate's Subject Name organizationName RDN
organizationalUnitName      = Whatever I entered at the prompt or was stipulated as the default
streetAddress               = Doesn't appear in CSR
localityName                = The issuing CA certificate's Subject Name localityName RDN
stateOrProvinceName         = The issuing CA certificate's Subject Name stateOrProvinceName RDN
countryName                 = The issuing CA certificate's Subject Name countryName RDN
postalCode                  = Doesn't appear in CSR
emailAddress                = Doesn't appear in CSR

Now let's use the 'ca' command to sign an existing CSR.  Using the values contained in the same [ policy_basic ] policy section, are the following CSR Subject Name RDN values required to be present in the CSR before the CA certificate will be allowed to sign the CSR:
commonName                  =
organizationName            = The issuing CA certificate's Subject Name organizationName RDN
organizationalUnitName      =
streetAddress               =
localityName                = The issuing CA certificate's Subject Name localityName RDN
stateOrProvinceName         = The issuing CA certificate's Subject Name stateOrProvincenName RDN
countryName                 = The issuing CA certificate's Subject Name countryName RDN
postalCode                  =
emailAddress                =

I purposely only showed values for the CSR's Subject Name RDNs whose corresponding policy field value is "match" in order to focus attention on how the MATCH policy value works.
Are my examples correct?  If so, is it correct that the ca policy values that are present in the OpenSSL configuration file are applied when the 'ca' command in used to BOTH create AND sign certificates?

If I used the 'ca' command to generate a Certificate Signing Request ("CSR"), and no values were supplied for the "optional" policy fields, ...

Mu. THIS IS IMPOSSIBLE. The openssl ca command cannot generate a CSR, and never does. It does do several things, resulting in a quite long man page describing all the things it does, none of which is generating a CSR. Since it doesn't generate any CSR ever, it is meaningless to talk about the contents of something that doesn't exist.
The command that normally does generate a CSR is openssl req with the -new option (or -newkey which implies -new). The req command also uses configuration, but it uses different configuration than the ca command. In particular it does not, ever, use any policy section in the config file, so the contents of any policy section in any config file never matter to req. However, the attributes that req can (or does) put in the Subject DN are configured using a config section designated by the distinguished_name item, and in the 'standard' (upstream) config this section is [req_distinguished_name]. This is described on the man page for req, which is a different man page than for ca because it is a different command.
(For completeness, openssl can also generate a basic/trivial CSR from an existing certificate with openssl x509 -x509toreq. This is rarely useful.)

Now let's use the 'ca' command to sign an existing CSR. Using the values contained in the same [ policy_basic ] policy section, are the following CSR Subject Name RDN values required to be present in the CSR before the CA certificate will be allowed to sign the CSR: ...

Almost. Issuing a certificate is NOT signing the (or any) CSR. As I said on at least one of your previous Qs, if you look at a CSR and the resulting cert you can see the cert is different from the CSR. The openssl ca command, like any other ('real') CA, creates a cert partly using data from the CSR, and signs that new cert NOT the CSR.
With that corrected, yes fields (technically attributes but Eric wasn't strict about terminology) designated 'match' in the policy section in the config file must be in the CSR with the same value as the CA's (parent) cert, and as result the value in the new cert will be the same as both the CSR and the parent cert.
The order may be different: as described on the man page, openssl ca in the absence of -preserveDN or config preserve will construct the new cert Subject DN in the order specified by the policy config, regardless of the order in either the CSR or the parent cert. It is conventional to order the RDNs in X.509 DNs from 'large' to 'small' (Country, STate, Locality, Org, OrgUnit, CommonName) so commonly the order in policy and CSR will already be the same, but OpenSSL doesn't require this. Also you should be aware that while actual, encoded DNs are as I said usually 'large' to 'small', some programs and libraries follow the LDAP convention of displaying (and if applicable entering) them from 'small' to 'large' i.e. in reverse order; if you aren't aware of the convention this can be confusing.


Why can't we create a new SSL implementation? SSL implementations have been discussed a lot lately, due to Chrome's potential of switching off NSS (https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53pQgNR-DppMYwt9XvE6s/preview?pli=1&sle=true#) and OpenSSL with Heartbleed.

What are the major factors preventing someone with tons of resources (e.g. Google) from implementing a new SSL library that is more easily auditable/maintainable to ensure security in the future?

I understand an SSL implementation may be a huge project in itself, but other people have implemented clean room implementations before (e.g. BouncyCastle in Java). So surely someone with enough resources would have the ability to write from scratch, and it would be cheaper than trying to audit and maintain something like OpenSSL.

Writing a working SSL implementation is not hard when you do it often; I have done it four times already (for various customers, nothing opensource, alas). It takes about 3 days, maybe 4 or 5 if you want to do it correctly (at least that what it takes me)(*).

Producing a new SSL library would not be a problem, and neither would it be a solution. There already are several beyond OpenSSL, e.g. GnuTLS, PolarSSL, CyaSSL... See the Wikipedia page for a list. Most are open source.

What is hard is maintenance. It is the tiresome job of keeping the library up to date with new protocol versions, new features, interoperability issues (the workarounds needed to talk with other existing libraries which do not necessarily conform to the standard)... OpenSSL source code is sure hard to read, but that's because it has grown from an historically simple but ancient core, and developed extensions, new APIs, and creeping featurism, including a fair share of "fixes" to avoid compiler bugs.

(*) Excluding the full-featured X.509 validation. Path building, processing of all extensions, and handling of revocation, is quite a task. A primitive validation mechanism for specific cases is easy enough, but reasonably complete X.509 support is daunting. I would not like to implement such a thing in C.


Why is there a Cap on Password length? Why when we sign up on sites like Facebook and Gmail do our passwords have to be 8-12 characters in length, or some other cap? 8-12 spaces are finite, but you can make your passwords more "secure" by adding uppercase letters and numbers.

It looks like Gmail passwords cap out at 100 characters (as of Sept 14 2017):

I think that the real reason our passwords are capped in length is for matters of legality, above any shortcomings in cryptographic efficiency. If the company needs to access your account they will access your account and don't want any obstacles in doing so. At first I thought they put a cap on passwords because if they  store passwords with longer lengths on their servers they will run out of space on their drives, but char values like passwords doesn't occupy much space, it is just a bunch of letters and numbers after all. Perhaps PBKDF2 with HMAC can decipher passwords of any length, but it will increase CPU processing time in doing so as well as space on a drive (perhaps around 1GB for a very long password).

Should companies with very large data centres be able to accommodate the simultaneous hashing of all the users of their platforms?

Passwords are capped at 12 (or whatever that number may be, 100 for Gmail because Google has the money to accommodate hashing to 100 characters with ease on their systems) because password key derivation function techniques are currently not at a level to decipher passwords of longer lengths efficiently. This means if you wanted to make your password 250 characters long you wouldn't be allowed to because the company doesn't feel it would be equipped to crack your password should they ever have the need to in an efficient manner.

Are we truly free?
what motivation do we have to make our passwords more secure than "password" or "12345678" if there is a cap imposed on our security? It seems the message they are delivering is that you can be secure, but not so secure that it makes our job more difficult.

A lock will keep out most intruders, but the ones equipped to crack the lock will do so. Do we choose the lock that will keep the most intruders out, or buy any average lock and hope the ones that can crack it don't come by our houses?

By making our passwords more secure through the addition of uppercase letters and numbers we begin to limit the number of people who can crack the password but people will still crack the password if they want to.

If you don't mind me being blunt, I think you have a lot of misunderstandings in your post, and a lot of your conclusions seemed to be based on assumptions of what amount to conspiracy theories.  First, let's be clear about a couple things, which I feel should be sufficient to dispel some of your assumptions and conspiracy theories:

Google does not have the computer resources to crack a 100 character password.  The entire earth does not have enough computing power or energy to do such a thing.  In fact, even a truly random password with only ~20 characters is long enough to be uncrackable by anyone (presuming a simple brute force attack of course, and ignoring phishing/algorithm weaknesses/etc)
If google wanted access to your data they wouldn't have to try to crack your password anyway.  They could just update their source code to store the plain text version of it the next time you login.  The same is true for any website that you log in to.  Anyone running a server doesn't have to crack your password to read it: it is waaaaay easier than that.

As a result, your general statement that companies have password length maximums because that allows them to crack your password when they want to is, without exception, completely wrong.

So why are there maximums?  This question discusses that for many legacy systems:

What technical reasons are there to have low maximum password lengths?

Google is a separate matter: a 100 character maximum is not actually unreasonable.  I doubt anyone is trying to use 100 character passwords, and even password managers don't (because 100 characters is absolute overkill).  There may be technical reasons with their cryptographic algorithms that require a maximum of 100 characters, but more than likely it is an arbitrary limit put in place because some limit is needed, and there is no practical reason for having a password that long in the first place.

To reiterate one more point, there is a physical limit to the length of a password that can actually be brute-forced.  It comes down to energy considerations, and the minimum amount of energy required to run computers that could crack passwords.  The overall gist of it is that for long enough passwords, there isn't enough energy in the entire world to crack the password, even if you had infinite computing resources to throw at the problem:

https://www.reddit.com/r/theydidthemath/comments/1x50xl/time_and_energy_required_to_bruteforce_a_aes256/

https://crypto.stackexchange.com/questions/1145/how-much-would-it-cost-in-u-s-dollars-to-brute-force-a-256-bit-key-in-a-year

Also good reading for you, to help you really understand some of the issues around password length:

https://www.infoworld.com/article/2655121/security/password-size-does-matter.html
https://security.stackexchange.com/a/118457/149676
https://crypto.stackexchange.com/questions/1145/how-much-would-it-cost-in-u-s-dollars-to-brute-force-a-256-bit-key-in-a-year
https://www.reddit.com/r/theydidthemath/comments/1x50xl/time_and_energy_required_to_bruteforce_a_aes256/


Restore integrity of compromised live boot iso Assuming  that BIOS integrity can be restored by resetting with the manufacturers bypass code, can a USB device running a corrupted/compromised Linux distro be restored to a state of integrity? The distros are FWUL 3.1 and Qubes  respectively on a Acer E5-521 which has had it's hard drive and WIFI card pulled. Despite these precautions the attacker still has access via the wired Ethernet connection somehow. Can I isolate the USB iso and re-secure/ harden it?

If the iso file you have is not compromised, you can just reboot and load it.

The main issue is not the integrity of your system, but your Operation Security (OpSec). This is the issue that most people forget, and what brings them down. Hardware compromise is very difficult to pull of, software compromise less so, but operation security compromise happens all the time.


Has my server been compromised? (Ransomware related) I just received an email that corresponds to the description here, which was posted just a couple of hours ago:

https://myonlinesecurity.co.uk/pdfpart2-pdf-sent-from-my-samsung-galaxy-note-4-powered-by-three-js-malware-leads-to-locky-ransomware/

Since the sender was was admin@mydomain.tld, might someone have logged into my Ubuntu server, or was the email simply sent to the email service on my server, in which case it's just spam.

I couldn't find any evidence of unknown logins using last or in syslog, but there are an insane amount of these in syslog today:

postfix/smtpd[24558]: connect from jackofallthreads.co[128.199.182.74]
postfix/smtpd[24558]: lost connection after UNKNOWN from jackofallthreads.co[128.199.182.74]
postfix/smtpd[24558]: disconnect from jackofallthreads.co[128.199.182.74]

SSH login to my server requires a private key, and root login is disabled.

EDIT: Here is the email's Delivered history. Note I have email forward from $ME@$MYDOMAIN to $ME@gmail.com. How can glean from this whether my server was compromised?

Delivered-To: $ME@gmail.com
Received: by $SOMEIP with SMTP id $ID;
        $DATE
Received: from localhost ($MYHOSTNAME. [$MYIP])
        by mx.google.com with ESMTP id $ID
        for <$ME@gmail.com>;
        $DATE
Received-SPF: neutral (google.com: $MYIP is neither ... admin@$MYDOMAIN) client-ip=$MYIP;
Authentication-Results: mx.google.com;
       spf=neutral (google.com: $MYIP is neither ... admin@$MYDOMAIN) smtp.mailfrom=admin@MYDOMAIN
Received: from [$SOMEIP] (unknown [$SOMEIP])
    by localhost (Postfix) with ESMTP id $ID
    for <$ME@$MYDOMAIN>; $DATE

SSH login to my server requires a private key, and root login is disabled.

Is a sensible precaution for ssh.

  Since the sender was was admin@mydomain.tld

If you take precautions for your ssh, do you apply the same to your SMTP? You should at least have SPF configured for your domain. Do you? Is the SPF validated by your receiving MTA? This should prevent you getting emails not from a legitimate source (or at least cut down the noise).

Assuming tat SPF is not working end-to-end for whatever reason, have you checked the email headers to see if it really did originate on your servers? I think it's very unlikely it did, but if this is the case, then you have good reason to suspect that your server or the hosting environment has been compromised.

If not, then think of it as a wee prompt to get your email security sorted out.


Reading/Writing content of files - what can happen? I'm setting up a simple system that is using an HTTP server which is writing incoming data to JSON files in a specific directory. This is functioning as a very simple pseudo-database. For simplicity, assume Java and no direct exploits on the server software itself - users can send JSON, it is written to a specific file, and they can request the contents of all those files.

Am I missing a major security issue here? Can the users somehow abuse this design to get access in any way?

If you would call this a database, my fear is an attack vector similar to SQL injection.

If the OS is important (which I guess it would be), a focus on Windows and Linux/Unix would be nice.

If I understand what you are doing correctly this is a database implemented as services.  If the data is sensitive a lack of authentication can lead to significant security issues.  Users could read each others data, overwrite important data, and possibly copy all the data in some massive security breach.

In addition to the authentication issues you may have issues if someone wants to perform a Denial of Service attack on your site.  Without proper controls a flood of data could be written and fill up a disk that the server relies on.

Depending on how the data is retrieved (if the requests aren't sanitized) the user could use constructs such as path seperators to downloads important files on the Operating System (/etc/password for example).  If the user is in control of the name of the file being written in anyway they could also use path exploits to overwrite sensitive files allowing them access.


How do mobile apps prevent HTTPS MITM attacks when the user installs the attacker's CA certificate? I am using a mobile app that installs a fake trusted CA certificate and therefore can capture the HTTPS traffic of other apps. Most of the time, this MITM attack is successful.

However, I noticed that some apps are more secure than others, and they would refuse to connect to their servers when the MITM attack with a fake trusted CA certificate is taking place.

How do those apps detect the MITM attack? Is this happening on the client side or on the server side?

It appears that HSTS and public key pinning cannot be used to prevent MITM when the user has installed the attacker's trusted CA certificate. If so, which technology can?

Public key pinning absolutely can prevent MITM even with a trusted CA certificate.  The whole point of pinning is that the application knows exactly which certificate (hash, issuer, etc) to expect.  Even though the trusted CA can generate a "valid" certificate for the domain, it won't be the exact certificate that the application is looking for, so it will reject it.


Is it easier to calculate a partial SHA256 collision than a full one? Question: Disregarding brute-force, is it any easier to calculate a partial hash collision, in which only a certain number of bits match?

Reasoning: On many websites you find hashes for file downloads. That's nice for integrity checks from the original website, and very nice when downloading from mirrors to verify that the file wasn't changed.

I just put up a new file download to a website and added the SHA256 hash as well.
Checking it, I noticed that I didn't really pay attention to the full hash, and that I never do. Instead I usually look at the first few digits and the last few digits, and disregard most of the values in between, thinking if those match, the others probably will as well.

No I ask myself, if that is a potential "social" attack vector. Offer a manipulated download of a file that just matches the partial checksum.

Calculating a full hash collision of SHA256 has not been demonstrated as far as I know.
So this boils down to the question, if from the mathematical side it is any easier to calculate a partial hash collision for SHA256, preferably at certain bit locations at the front and back?

Let's consider brute-force still too expensive, since that will of course get easier with less and less bits to come out correct.

To clarify, the attack you are concerned about (someone substituting a different file that hashes to the same known hash) is actually a second preimage attack, not a collision attack. A second preimage attack is significantly harder to achieve than a collision attack.

That being said, in your described scenario of just matching some undefined (and presumably small) number of characters in a hash, a second preimage attack is certainly possible, and even likely if someone puts in enough effort. So, yes, it is (obviously?) easier to match fewer characters of a hash, than more.

As a side note, if someone were able to somehow access your server and swap out the file with a different one, it seems reasonable that they could likely also change the stated hash value as well, which arguably would be a much easier and more effective attack than generating a file which partially matches the stated hash.


Evaluating spam score for a single page application I am developing a single page application with a behaviour similar to google Maps and I want to avoid spam as much as possible.
Users can register on my website to get access to an API KEY. Then, on their website, they can implement this single page application like this :

<script src="https://www.mywebsite.com/single_page_app.js?key=THEIR_API_KEY"></script>

(Plus a few line of javascript to bind the app to a <div> but that's not relevant)

This single page application will be used by end-users to fill informations (options, date, email, names...) through a multi-step form. Each end-user has a session (cookie are used with CORS request) and a token is sent to the application to avoid CSRF. At the end of each step, the collected data is sent to my server with the token and saved into my database.

How can I evaluate if the data sent to my server is spam ?
I've got a few (obvious) ideas which are :

Validate the data sent
Analyse the time between steps and the total time spent
Count the number of request by IP
Look for request with the exact same data (md5 hash)
Look for the Origin and Referrer Header (CSRF, not really spam)

Is there anything more I can do ?
Moreover, some verifications (like the number of request per IP or the duplicate data) can be time consumming as I have to look through my database.

Should these verifications be made by a CRON process after being inserted into the database or on-the-fly before inserting them into my database ?

What should I do with SPAM data ?

SPAM data can be usefull to detect futur spam, should I delete it or keep it somewhere ? For how long ?

What happens to your database?  Think from an attacker's perspective and look for ways to abuse the system.

There are three methods a form/API can be used to spam:

The submitted data shows up on a website
The submitted data is sent via email (usually to a small and fixed set of people)
There is a vulnerability in the implementation that can be exploited to use your site to relay spam in another manner (review your code! this method is not otherwise discussed here)

If the data is shown on a website (or if an attacker makes that assumption), you're likely to see comment spam aspiring to:

Perform search engine optimization
Spread malware (by link and/or attachment)
Damage your site's credibility or otherwise provide noise
Troll you or users of your site
Spread fake news or other propaganda (essentially #4 and #1)

You can combat form→email spam and web comment spam as follows:

Use blacklists like URI DNSBLs to combat link spam
(Web only) Render links with nofollow, like this
Do not allow attaching non-media files
Rate limit:  “Too many submissions from this IP, try again later”
Limit privileges for newcomers, e.g.

“You can't attach files until …”
“You can't provide links until …”, then use nofollow, then allow fully
“You can't post images until …”
“You can't post more than once an hour until …”

Have a moderation team review every post before it goes public

(Web only) Crowdsource it! Consider a user moderation system like Discourse

Build a machine learning algorithm to automate the human moderation team
Implement a captcha (and make it harder for newcomers than for regular users)

The less visible "success" is for an attacker, the less persistent attacks will be (though some attackers don't care).  Even claiming to have moderator review but merely delaying a new user's posts by a few hours may thwart some spam.

If you're sending email, you can use one of many Bayesian systems internally to see whether you want to drop the submission from your database and/or from pushing externally.  ( You'll still have to regularly train this system.)  You may also want to use an Email Service Provider (ESP) to handle your outbound reputation for you.

You can report spam images to Knujon ("No Junk" spelled backwards) in its image-only file upload. You can report phishing landing sites to PhishTank.


What are the risks of using OAuth for authentication when in control of both ends? I recently discovered that the applications in our system used plain Oauth2 instead of OpenID Connect to authenticate users. The original use-case was to use OAuth to allow our users to authenticate on the applications using the main application's account, all of which are under our control.

There are a lot of posts around pressing on the fact OAuth is an authorization protocol and as such should not be used for authentication. While I understand the difference between the two notions, I'm having trouble finding information about what actually is the risk of doing so, and what kind of attacks could be made on the system and lead in a user being impersonated.

All I could find were either attacks that weren't specific to the authentication use-case (CSRF during the authorization procedure for example) or implied a malicious client application reusing the user's authorization. But these threats seemed only pertinent when using public services such as Google or Facebook as identity providers. In my use-case, both identity provider and clients are under control, effectively denying the threat of a malicious third-party client.

As such, what are the risks associated with using OAuth to authenticate users when all clients are under control?

The problem with OAuth2 is that the authorization_code given out by the OAuth2 Provider, is not bound to the client_id of the OAuth2 Client.

This means that if a user authorizes a malicious service to access its OAuth2 resources, the malicious service could use the authorization_code it received to 'impersonate' the user on another service, if the other service mistakes authorisation for authentication.

To answer the question:

IF you can guarantee that you control ALL clients ALL the time, you are probably fine. However, you are still using a OAuth2 outside of its intended scope. Using a security protocol outside of its intended scope is generally considered very bad practice.

For example, there is a real risk that somebody, at a later date, decides to alter the scope of the project; it happens all the time.
If this happens, you might suddenly find that the assumptions you made earlier, are no longer true. If these are the very assumptions that made you feel confident enough to go ahead an build your authentication on bad practice, your authentication is suddenly vulnerable to impersonation attacks. Chances are, you will only find out when people start reporting strange incidents.

In summary: if you want Authentication, you should use OpenID Connect instead. OpenID Connect is the authentication layer build on top of OAuth2.


ip-fragmentation and mod_security? is it possible to use ip-fragmenation (for example with fragroute) to evade mod_security?

the idea would be to split a sql-injection- or xss-string into little pieces so it s not recognised.

AviD was on the right track with the idea of taking IP frag attack concepts for evading network level IDS and applying it to layer 7 http data.  If you wanted to split up say an SQLi payload so that it may evade input filters and still work against the back-end system, the attack technique is called "HTTP Parameter Pollution (HPP)".  HPP is an attack where the user sends a request where multiple parameters have the same name.  In these cases, there is a wide level of variance in how the apps will respond.  Will they take the first payload?  The last?  In the case of ASP/ASP.NET sites, they actually will concatenate all payloads with the same name. This allows for a "fragmentation" type of attack.  See my previous blog post on the topic -
http://tacticalwebappsec.blogspot.com/2009/05/http-parameter-pollution.html

and here

http://tacticalwebappsec.blogspot.com/search?q=parameter+pollution

Also of note - the current version of the OWASP ModSecurity Core Rule Set (CRS) has an experimental ruleset for HPP which will mimic ASP and concatenate any params with the same names into custom TX variables for inspection by later rules -

http://mod-security.svn.sourceforge.net/viewvc/mod-security/crs/trunk/experimental_rules/modsecurity_crs_40_http_parameter_pollution.conf

Cheers,
Ryan


Virus checking and cleaning an external hdd Is it safe to scan and clean an external hdd of malware/virus on an otherwise clean system ie my system!?

Does the antivirus software on my machine do it's work externally? ie if a virus is detected does it quarantine the object to somewhere on the external hdd rather than onto my machine?

Would using a separate user account for this work be of any benefit? Thanks.

Are you sure tour system doesn't have an application that scan or index new devices? Like a media player that tries to extract metadata from multimedia files.

I would recommend booting from a live CD or live USB in read-only mode, not mounting your partitions, and disconnected from any network. After that load [a VM with] your antivirus, then mount your external drive and check it. However, this will not prevent a rootkit from infecting your BIOS and you will have no guaranty that your antivirus found all the malware. It's still better than nothing.

If you want a bullet proof method to remove your virus from the drive, the only way is to destroy it. Erasing it is not enough, as its firmware could be infected.


offline root CA workflow I have reviewed several discussions here regarding offline root CA management. While useful, none quite capture my question.
Firstly it presumably would not be generally assessed as an 'offline' root if its key is in a network connected HSM, no matter how protected (with a PIN, behind firewall, etc)?
In my setup a physical laptop or desktop, which can be disconnected and off and physically secured is probably not feasible. So I'm thinking of something like a Tails bootable USB. Boot from this on a host and use an encrypted partition of Tails to store the root key and thus issue the root CA from that environment.
As the online intermediate signing CA cert has to be issued by the root and be online (with key via an HSM), how do I get that issuing CA certificate request into Tails to create the certificate sufficiently securely?   This seems that sneaker-net is essential and the use of USB storage is mandatory.
Does having two HSMs make a good solution? One contains the root CA key, which is powered off except when needed, and another online one for managing the issuing certificate's key?
Publishing a CRL by the root CA is another component of the ecosystem that is tricky.
Another aspect of which I am unsure is if creating, as far as is possible, a known untampered Tails USB instance is possible, is its use on a general use laptop or desktop safe enough?  If the USB is read-only I can't store anything on it - such as an issued certificate.  If it is read/write then a vector exists to compromise it from the laptop/desktop on which it is used.
I'm seeking opinions on the workflow for using 'offline' root CAs more than the technical steps involved.  I realise these design decisions are driven by risk appetite and consequences. Guidance and the lived experience would help. Thank you.

Firstly it presumably would not be generally assessed as an 'offline' root if its key is in a network connected HSM, no matter how protected (with a PIN, behind firewall, etc)?

any reason for such assumption? HSM ports are not switched (at least this is the case in nShield net-HSMs). In my opinion, offline CA is CA that cannot be accessed over network and is physically secured. From what I know Tails OS doesn't equal HSM.

sufficiently securely

this is a too broad term. You should clarify what is "sufficiently securely" for you.

Does having two HSMs make a good solution? One contains the root CA key, which is powered off except when needed, and another online one for managing the issuing certificate's key?

single net-attached HSM is sufficient (though, this creates a single point of failure. If single HSM fails, you are screwed) for normal operation. HSMs support partitioning (key isolation) using different techniques, such as operator card set. Having one card set (quorum), you can access only subset of keys stored on HSM, not entire HSM.

If the USB is read-only I can't store anything on it - such as an issued certificate. If it is read/write then a vector exists to compromise it from the laptop/desktop on which it is used.

The purpose of secure cryptographic storage is to store keys. CA software is installed on a standard/normal OS installation, Windows, Linux or Mac and executes its workflows, such as accepting and signing requests, signing CRLs, maintain internal database, configuration and so on. The highest value of CA is its private key which is stored on secure device such as HSM. This means that booting from custom USB OS doesn't give you any benefit since you cannot activate CA software from USB OS unless such functionality is offered by USB OS.
I would say that Tails USB OS doesn't solve your problem and you should take a look at HSM technology.


Best practice for creating an initial IPS policy I see that most IPS available in the market comes with a basic pre-defined policy which administrators can base on when creating their initial IPS policy. However, these policy may be insufficient and the administrator may need to dig deeper. As such what is the best practice when creating an initial policy and making sure nothing gets missed out.

Of course we will be given a list of applications, OS, known ports, etc in a network and we can create a policy from there; but do we keep it strict and limited to the list given to us or do we loosen up a bit for wider protection coverage.

For example, if a web server is running Microsoft IIS but not FrontPage, do we enable rules / signature for both IIS and FrontPage Extensions to ensure that the IPS will be able to pick up FrontPage exploit / probing attempts?

Also, how do we ensure that the usability, functionality and security as well as the performance of the IPS itself is not affected by the IPS policy we've created as some of the rules / signature in certain IPS solutions that I know have overhead / performance impact.

I would normally advice to deploy your IPS in non-blocking mode to start off with running the default policy, plus any other signatures\policies that specifically apply to whats running on your network.

Once that policy has been up and running for a while and you are happy with the following

The false positive rate
The performance stats (packet drop etc), especially under high load (pps,throughput)
The tunning you have done to eliminate false positives

Then you need to consider whether to broaden the set of policies enabled. In doing so you need to consider the following.

Have you full control over applications\nodes deployed on your network ?
Will you be alerted if new applications\nodes
appear on your network ?

In an ideal scenario your IPS will only have signatures enabled which cover the applications running on your network. The advantage of doing this are as follows.

Lowers the possibility of a false positive blocking legitimate traffic, the less signatures enabled the lower the false positives.
In general the lower the number of signatures enabled means better performance reducing the chances of malicious traffic going undetected due to performance problems.

Once you have this done you should consider enabling blocking mode on your IPS.


Is it possible to inject HTML into image to provoke XSS? Some answers mention that it's possible to inject attacker-controlled HTML into images and therefore provoke XSS.

I guess that this HTML will be processed by browser only if hole exists in browser. So I think it's more a browser issue and there is no need to convert those images, strip EXIF metadata, randomize them at web-application's side.

Is attacker able to inject HTML into image that will provoke XSS? If yes, how?

I'm pretty sure bstpierre was talking about a situation, where you let users upload images to display in a gallery and furthermore you display meta-data about that image taken from EXIF tags.  If the EXIF tags were specifically constructed with malicious html tags, and there was no input sanitation (e.g., escape characters like <, >, &, so they are rendered in the page like &lt; &gt;, &amp) you could conceivably use them for an XSS attack.  Again, it is not a problem if your web app sanitizes all user-input including extracted tags from image files.

bobince was talking about a few totally different things; the closest being that someone uploads a file - say fake_image.jpg but instead of being an image, the content is actually a html file.  By content sniffing, he meant that some browsers, when you click to open up a page http://example.com/fake_image.jpg can figure out that fake_image.jpg is not an image but instead a html file and will display the html page in the file.  Thus, the uploaded html file (with an image file name) could be used in an XSS attack.  For this attack to be useful, you have to have a browser that allows this sort of content-sniffing, and then you have to go to the URL of the image (not just have <img src='fake_image.jpg'> embedded in the page).


Do PKCS #11 keyfiles on a yubikey actually improve security for Veracrypt? I am trying to understand the benefits of a PKCS #11 keyfile stored on a smartcard such as a YubiKey with regards to Veracrypt volumes.  Am I correct that the file will be taken off of the hardware device to be used?  If so, this would seem to expose it to software running on the system therefore negating most or all of the benefits of a hardware token.

Am I missing something?

This question is indeed a very good one. I'm no expert but since nobody is jumping in (I guess because questions that already have at least one answer are less attractive).
Florian's answer to this question is just a boilerplate of how things are supposed to work with PKCS11 but not at all the way the standard was implemented in Veracrypt.
As the developers acknowledged recently here Veracrypt does not support asymmetric keys. If you try to use an RSA key from a smartcard as a keyfile the window "Select Security Token Keyfiles" will come out empty. Quoting from the link:

...I also have the idea of modifying VeraCrypt format in order to support using Asymmetric keys (RSA or Elliptic Curve) that are stored on such cards or tokens: these keys will be used to decrypt the header volumes instead of relaying [sic] on the password. This will provide stronger security and but it also requires a big development effort while at the same time targeting a very small number of potential users...

That's that then, private keys (CKO_PRIVATE_KEY) are out of the question, what about symmetric keys (CKO_SECRET_KEY)? Nope, that's not supported either.
How exactly is PKCS11 supported then? Well... if you take a look at the code: SecurityToken.cpp you'll notice on line 215 a reference to CKO_DATA. Let's go take a look at the PKCS11 standard to find out what that is:

Data objects (object class CKO_DATA) hold information defined by an application. Other than providing access to a data objects, Cryptoki does not attach any special meaning to a data object.

So, if it's not a key (public, private, or secret) and it's not a certificate it will be a data object (no strings or special meaning attached). I don't know exactly what was the original idea behind this kind of object, what I know is they ended up being used for different things, the one I've seen most frequently is to store personal data. One example could be your name and address on a European national eID card or your picture on an ICAO compliant electronic passport.
Is this CKO_DATA object supposed to be used to hold keys or passwords? I don't think so because if you do that you are basically giving up all cryptographic features of the smartcard or token.
Is this better than storing your keys on your disk unprotected and unencrypted? I guess it is, at least on most tokens your keys will be password protected. I would agree it is the same as storing your keys on a password-protected non-cryptographic USB drive.
On this topic, I'm sure you will find all kinds of opinions. There was an interesting debate on the opensc github some time ago.


Looking for a way to overwrite a symbolic link I'm peparing for OSCP and I found an interesting situation (Alpine Linux).

There is a daemon super_service executed by root that is reading configuration file from /var/super_service/configs/ which is a symbolic link to location that my user john has no write permissions.

$ id
uid=1000(john) gid=1000(john) groups=1000(john)

$ ls -la /var/super_service
drwxr-xr-x    2 root     root          4096 May  9  2019 .
drwxr-xr-x    3 root     root          4096 May  9  2019 ..
lrwxrwxrwx    1 root     root            13 May  9  2019 configs -> /etc/super_service/configs

$ ls -la /etc/super_service/configs
drwxr-xr-x    1 root     root          4096 Jan 29 12:10 .
drwxr-xr-x    1 root     root          4096 Jan 29 12:10 ..
-rw-------    1 root     root           283 Jan 23  2019 root.cfg

Potential flaw is that /var/super_service/configs/ symbolic link permissions are rwx for everyone. If I manage to "redirect" this symbolic link to location controlled by me, I'd be able to control the config file read by super_service. Unfortunately, due to /var/super_service permissions (r-x) I'm not able to remove or replace this symbolic link.

I wonder if this situation is exploitable in any way?

My understanding is that if /var/super_service/configs would be regular file, not symbolic link, with exact permissions I could overwrite this file. But is there an equivalent of overwrite that is applicable for symbolic links?

No, that's not exploitable. Write permission on links is worthless in practice. To re-target a link, you need write permission on the parent directory. To modify the file or directory that the link is targeting, you need write permission on the target. Write permission on just the link lets you do neither of these things.


Surveillance in the Workplace? Auditing, surveillance and logging are typical and common place in the workplace, understandably so. These actions are crucial to establishing metrics and performance of the network and its resources.

The surveillance can take many forms, namely:

Company Cell phone passive audio recordings in and out of the workplace
Key loggers
Traffic including SSH traffic that was MITM'd (banking stuff, private emails)
Instant messages and texts.

The CIA triad's first element is confidentiality, and in the context of IT infrastructure this relates to confidentiality of the corporation's communications and data. This leads to an uneven dichotomy where individual's rights to privacy are compromised in this effort to secure IT infrastructure.

Since laws are the threshold between what is right and wrong in the context of a country's laws, why are there no disciplines in certifications (ISC2 CISSP, SSCP, etc) that propose balancing out the right of the individual and the requirements of the corporation?

Edit: try to ask the question in a better way

Laws on computer surveillance are derived from laws regarding telephone surveillance and wiretapping.  Those laws don't always fit the current situation, and the laws have not kept up with rapidly changing technology.  So there are lots of holes in regulation and privacy law.

One important concept is the "expectation of privacy," where a reasonable person would expect a conversation to be private -- say inside one's home as opposed to a busy street corner. If you don't have the expectation of privacy, you can't argue that your conversation (data, web history, etc) is private. This concept governs most computer privacy laws.

To answer your questions:

In the organizations I've worked at (in the US), there are no limitations, other than most IT shops are too busy to bother with weeding through collected data unless something very bad is going on.  As storage gets cheaper and cheaper, the tendency is to collect everything -- just in case (the NSA is a perfect example).
There are laws regarding privacy, but they vary from state to state (and apparently from provence to provence).  How much security one needs is up to the organization to determine themselves, so guidelines aren't much help.  I've never seen anything commonly used.
The idea is that in the workplace, the company owns the computers, circuits, storage, etc, so any information you create on them belongs to the company, especially since you are being paid to be there.  Again, there's also the expectation of privacy thing -- you normally don't expect your conversations at work to be private.
A lot depends on what kind of surveillance, and what state it is taking place in.

Just for the record, IANAL.


Are we gossiping in Certificate Transparency? Ben Laurie's original paper on Certificate Transparency proposed that clients (browsers) should "gossip".  In particular, it proposed that when a browser connects to a web server, it should send to the server the latest signed tree head from a Certificate Transparency log.  This enables comparing what different browsers are seeing, and enables detecting some attacks where the CT log server equivocates and serves different logs to different entities.  However, the paper also mentions that this idea is tentative and still being explored.
Was anything like this ever implemented and adopted?  What was the ultimate decision on gossip?

Doesn't look like gossiping is going to happen at scale
I think Emily Stark is in charge of CT on the Google Chrome side. And I think CT was largely a Google brainchild, so she is probably a good person to listen to.
And she wrote a nice primer on CT last year:

https://emilymstark.com/2020/07/20/certificate-transparency-a-birds-eye-view.html

Gossip is mentioned as such:

There has been an attempt to define gossip protocols for exchanging STHs, but they haven’t been widely deployed yet. Most likely, centralization will turn out to be key. It’s not particularly likely that every browser user will gossip STHs with every other browser user, but it is more feasible for a handful of browser vendors to gossip with one another and then distribute these gossiped STHs to their users.

And she posted a CT thread on Twitter yesterday:

https://twitter.com/estark37/status/1367179923845128193

There gossipping is NOT mentioned. Instead it's about SCT auditing. Which, if I understand correctly, does mostly the same job as gossipping: It verifies consistency.
Most relevant tweet there:

4/ While SCT auditing has been talked about for years, no browser that I know of has ever actually deployed it.

Something a little older: Andrew Ayer blogged in 2018:

https://www.agwa.name/blog/post/four_years_of_sslmate

and he mentioned this:

In March 2017, SSLMate started operating the world's second Certificate Transparency gossip endpoint (Graham Edgecombe gets credit for the first) to provide further resiliency to the Certificate Transparency ecosystem.

And he points to Graham Edgecombe's site:

https://ct.grahamedgecombe.com/

And there's only three gossip monitors listed in total. So not a lot. (But maybe I'm confusing the centralized vs. decentralized gossip again, here.)


What risks are involved in exposing our home computers over the public internet? I'm currently running a webserver from home accessible on the public internet via a static IP. What kind of risks  are there in doing so?

From what I understand, the setup will not allow connections besides port 80 and thus my network and computers are safe from attacks, but is that  right?

What are some steps to take to minimize the risks involved?

Well, the general recommendation would probably be something along the lines of:

Put a firewall in front of your web server. Only allow the traffic you need to allow, and deny (drop or reject is largely a matter of preference) everything else. You have already done this, but there's more to it than just running firewall software.
Go over the software configuration with a fine-toothed comb. Especially consider anything related to file uploads, execution of code, and things like that.
Keep everything that is even potentially exposed to the Internet fully up to date. This includes the operating system, web server, anything served through it (remember that those PHP scripts that let you upload and view files are executable computer code that can have security-related bugs) and anything that those applications rely on (such as for example a database server).

Even in the best case, your setup will only ever be as secure as the least secure portion of whatever is accessible over the Internet. The instant you start accepting packets from the Internet rather than flat out blocking everything, there is always the risk that a bug in the operating system's TCP/IP stack, the software that handles the packets, or where the data coming in eventually ends up, could cause the computer to exhibit behavior other than that desired by you (A.K.A. a security breach of some kind).

As soon as a fix for a security-related problem becomes available, lots of eyes start going over it to see if they might be able to exploit what's been fixed for illicit purposes.

Any host connected to the Internet will see regular scans from various bots. Some are harmless; some are stupid enough to be essentially harmless; but some are actually potentially dangerous, and HTTP on port 80 is common enough that you should expect plenty of such traffic. That you don't have a host name pointing at your IP address doesn't change that fact. Which means that the web server and whatever is running on it will have to be able to deal with anything anyone can throw at it based on currently known security vulnerabilities in any web server software and version (since the attacker won't know exactly what you might be running).


Protecting OTP based authentication Let's say I have a website which uses 4 digit OTP based authentication for login i.e. users will enter their mobile number, receive OTP on the entered mobile number, enter the received OTP to login successfully.
I have an approach on how to crack such a login based mechanism if I have access to a subset of all registered mobile numbers, and I want to know whether it will work and if yes how to protect against the same.
Let's say I have a list of 100,000 mobile numbers registered/using such a website.
Now, I will do the following process multiple times.

Pick a previously unused phone number from the list of registered phone numbers.
Hit the service to send an OTP to the registered phone number ( which I do not have access to ).
The website in background will generate a random OTP and send it to the registered mobile number.
I will generate a random 4 digit OTP and try to login using the same.

Now, the probability of the above process succeeding is: 10000 / (10000 * 10000) => 1 / 10000,
because in every process a pair of 10,000 faced dice are rolled, and above is the probability that both of them will have same number on the top.
So, if I repeat the above process at least 10000 (expected value to get a match) times, I should be able to login using at least one phone number with high probability.
How do I mitigate such an attack ?

It doesn't matter how many mobile phones you have, each attempt still has 1 in 10000 chance of succeeding given a 4-digit PIN. What's important is how many attempts you have, which might not be tied only to a specific phone number but also to where the request ia coming from. This is one way to mitigate such attacks. Another is increasing the complexity of the OTP code, which is strongly encouraged in this case because 4 digits is definitely not secure enough if not paired with another for of authentication (username/password). Ideally introduce letters as well.


Subject Alternative Name in Certificate Signing Request apparently does not survive signing So I have been able to create a Certificate Signing Request with a Subject Alternative Name of the form subjectAltName=IP:1.2.3.4 by following the recipe in a previous (splendid) answer.

When I inspect that CSR with openssl req -in key.csr -text I can see a corresponding section:

Requested Extensions:
  X509v3 Subject Alternative Name:
    IP Address:1.2.3.4

I then proceed to signing the CSR with a self-signed key like so:

openssl x509 -req -days 365 -CA ca.crt -CAkey ca.key -CAcreateserial \
  -in key.csr -out key.crt

The resulting certificate (when inspected with openssl x509 -in key.crt -text) does not identify that section any more.

Is this just an artifact of display parameters or need I also instruct openssl x509 that it should include the extension when doing its signing (and if so, how)?

I am using OpenSSL on macOS High Sierra (openssl version reports LibreSSL 2.2.7) and have not changed its configuration from the defaults. The keys will ultimately be used between Debian (Stretch) servers, so I could perform key generation there, if it helps in this context.

The following command apparently resolves the issue:

openssl x509 -req -days 365 -CA ca.crt -CAkey ca.key -CAcreateserial \
  -extensions SAN \
  -extfile <(cat /etc/ssl/openssl.cnf \
    <(printf "\n[SAN]\nsubjectAltName=IP:1.2.3.4")) \
  -in key.csr -out key.crt

It is the same recipe as for openssl req, but with the two parameters extensions and extfile instead of reqexts and config.

This command was helpful for quickly confirming the desired outcome by printing the relevant section:

openssl x509 -in key.crt -text | grep "Subject Alternative Name" -C 1


What file formats are known to be unsafe? I recently found out pdf's can contain viruses, and from the impression I got its more than a buffer overflow error (I heard it may visit urls automatically but the person sounded unsure)

What are some formats that I should be wary of until everything is patched?

I remember at one point there was something in a vb6 project that would execute code on project loadup (without running). That was dangerous.

Some formats can be called inherently insecure due to their complexity and their history of use as attack vectors. Adobe PDF and MS Office files come to mind. Any kind of binary executable is certainly problematic unless sandboxing is deployed.

But in general it depends on the application that is used to open the file, not the file itself. Even simple formats that cannot embed executable code can be parsed by an application in the wrong way, leading to bugs and potential vulnerabilities. Similarly, the sandboxing application may have bugs that allow executable code to escalate its privileges, so I would rate a sandboxed executable about as dangerous as complex file formats.

It may be possible to have relatively secure file formats by using a data format that can be checked automatically, using an automatically generated parser that does not need any information about the file type except the used grammar. I think the ASN.1 format is a candidate for this. But this kind of technology is used almost nowhere.


How do I detect malware on Mac OS X? I have a computer running OS X, and I want to know if there's malware (e.g. a keylogger, or something that lets an attacker control my computer, or something that stops me from installing whatever I want) installed on the computer. How can I tell if I have something like that? How can I remove it if I have it?

A lot depends on the relationship between you and the machine - is it your own? Do you have administrator access to it? Since you mention that it's corporate owned, do you have an administrator that has ok'd a keylogger (for whatever reason)? It's possible (or, in fact, likely) you won't be able to remove it without drastic steps - specifically without re-imaging the machine with a known-good OS install. I don't know of any corporate environments where they'd let you do that.

Unfortunately, with a corporate owned machine, they're likely allowed to install whatever they want, and any measures you take to circumvent the logger may well get you fired.

Some things that you may be comfortable trying though:

It may be worth installing an anti-malware tool of some sort - from any of the big vendors Norton, McAfee, etc. - and seeing what turns up. You may be able to sell this to your administrator by pointing out that Macs get malware too, and that you'd like to be protected.
See if you can get chkrootkit to run, as most keyloggers are rootkits.
See if you can get Little Snitch installed; keep an eye out for anything suspicious. Any keylogger is only useful to an attacker if they can get that info out somehow.

Unfortunately, since a keylogger is likely to have revealed your passwords, etc. to an attacker, and is generally a sign of a relatively sophisticated attack - it's very likely that the logger itself has managed to get itself installed as a kernel module or rootkit and so even a clean AV sweep isn't an indication you're clear. You really need to consider that just wiping it may be your only option; start fresh and if you're worried about people you know breaking in, keep a close eye on the machine, keep it locked when you're away and keep your passwords complex and secret.


How much of a Django application could be reverse-engineered if the owner forgot to turn debug mode off? I've been writing a Django app and almost published it with debug mode on. Django's documentation indicates

Never deploy a site into production with DEBUG turned on.
Did you catch that? NEVER deploy a site into production with DEBUG turned on.
One of the main features of debug mode is the display of detailed error pages. If your app raises an exception when DEBUG is True, Django will display a detailed traceback, including a lot of metadata about your environment, such as all the currently defined Django settings (from settings.py).

So I'm wondering how much information could a malicious attacker actually gain in a typical app? Users logins? All your code?

This is highly dependent on the application in question.

So let's say for example you have a django web app that has many programmatic errors (not vulnerabilities). In this case you would be able to generate a lot of highly verbose error messages. If you were able to actually disclose the full contents of settings.py then you would be in big trouble. Your database connection string, CSRF token, cache keys, possibly AWS keys etc are all stored there. You would also be able to, as you mention, reverse engineer some application logic. This behavior can lead to a more targeted attack such as making it easier for me to find XSS or SQL Injection.

Now let's take the opposite case. You deploy an app that is flawless: the impact is much lower, as you will not be disclosing quite as much data. However given the size of the code base your application is not and will not be flawless, so take care to never deploy in debug mode.


Should email verification links be 'time limited' after user registration? Regarding web application user management, I understand that password reset links are effectively "password equivalents", and therefore it makes sense to limit them to one use only and also make them expire.

But what about the email verification links after user registration? This isn't a "password equivalent", just a step to confirm the submitted email address does belong to the user.

Should a time limit also apply to email verification links?

A time limit for a verification link is a small part of the overall security model for your system.  The main risk-benefit is that if the link is compromised then the same verification link cannot be used in the future (if the user never got around to using the one-time verification link).  The link could be compromised by a future user email hack, results being evaluated from network scanning and so on.  The theory being that it takes some time to compromise the link itself and then act on it.

It's a pretty low probability risk, however, it makes sense to implement a time limit.


Does limiting a web session to one browser window or tab provide added security? A certain tax website has the frustrating feature of limiting the session to only one browser tab or window at a time. I haven't looked into how they might be doing this, but if you login on one tab, then open another tab and go to the same URL, you are logged out of your session on both tabs. They claim...

Tax returns contain sensitive information, and so our security procedures are stricter than you may see on other websites. You won't be able to have two tabs open in the same account.

Does this actually provide any additional security? If so what type of attack would take advantage of this? (My hunch is it is just a limitation of how they're managing state in their single-page web app.)

Limiting the session to apply to only one tab can be a useful protection, even though it comes with a usability downside that probably makes it not worth it in most cases.
Some attacks (e.g. reflected XSS, CSRF or clickjacking) rely on the attacker tricking the victim into clicking a link. The risk of the victim clicking such a malicious link is decreased if it has to be done in the tab with the open session. In the same way that logging out when you are done protects you over time, keeping the session to one  tab protects you over "space".
So limiting the session to one tab can sort of make sense. What I don't get is why you would be logged out in both tabs when you open a second tab, insead of not just being logged out in the second tab. Maybe they wanted to get the security benefits I describe above and couldn't figure out a better way to do it? Or maybe you are right, and they are just using security arguments to cover up bad design.


Confirming VPN is secure I'm staying in a Hotel for a couple of nights and I will want to use any available public wi-fi on my android device that may include banking logins and password logins. I'm relatively new to using VPN's so kind of need some reassurance about it.

I came across CyberGhost as being a highly rated free VPN service and currently have it running on my device. I've been to ipleak.net and it looks like my vpn created ip address is working correctly, I don't have a webRTC leak and a 3rd party DNS server is being used, all good things right...

Based on this does it sound like this vpn is secure? I'm under the understanding that once connected to a vpn all traffic is encrypted right? Are there any other precautions I should take?

I do not see free VPN solutions to be secure. Because you have to ask yourself why is someone providing you a service (of  "encrypting" you data and tunneling it for you) for free.

The best thing to do in your situation is to use SSH dynamic port tunneling.
You need a machine you can trust, let's say you set up a Raspberry Pi running 24/7 at your home with some Linux distribution and OpenSSH packet installed.
You need to be listening on a port you specify to wait for a connection and once connection occures your Raspberry Pi will encrypt your traffic while acting as a proxy.
You will have to configure SOCKS Proxy in your browser to point to and IP address of your Raspberry Pi. Also take care of NAT if RPi is behind it with port forwarding and use a service like no noip.com so you can reach your home network if you don't have public static IP.
I would recommend you to use certificate based authentication for SSH and to turn off root login and user login with password so nobody can use wordlist attack on your RPi box.


Why do websites still suffer from OS injections if by default web-servers are not assigned a shell? So even if there is some poor php written which allows a shell_exec() and that someone disabled safe mode on it, what exactly are the risks? Do admins just change the default group or are most attacks coming from other forms of web applications which run as privileged users?

Apache for example runs as user "nobody" which is assigned to either /bin/false or /usr/sbin/nologin which should prevent getting a shell anyway.

Using shell_exec() and its multiple variants is perfectly fine so long as the web server's user account is limited to its directory structure.

The real risk is to use unsafe scripts that run commands with user input.  escapeshellcmd() and escapeshellarg() can be used to make that safer.

Note that having no login shell does not prevent from running commands through a shell.

As for PHP safe mode, it is long outdated (as shown on http://php.net/manual/en/features.safe-mode.php):

  This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0.


Use multiple AntiVirus engine I’ve found some codes and AntiViruses which use multiple Antivirus’s engines in their products. Like https://github.com/joxeankoret/multiav and some other code or products.

How?

and
What about License?

There is typically no reason for programs not to interact when the programs offer some sort of API - in the case of the linked product, it answers your

  how?

In the readme:

  It uses, with the only exception of ClamAV, the command line AV
  scanners and extracts the malware names from the output of the command
  line tools (for ClamAV it uses the https://code.google.com/p/pyclamd/
  extension).

As you asked for an actual example: let’s say a anti virus solution has a CLI that works like this:

av file returns either ok or bad.

A program can now call av file, for example via a system call and read the output of that CLI, then decide with a string matching on ok or bad to decide what to present to the user for this particular file for this anti virus.

This can be repeated for as much CLIs as supported.

As to the licensing: of course the supported AV solutions must be present and functional on the machine, leaving this to the user.

In an attempt to make this on-topic, I will highlight why it is useful to use different AV products on files.

As some examples on virus total show, individual anti virus solutions have vastly different results in identifying malicious files.

This for example comes from:

different paces and update cycles of different vendors due to different office hours and analysis priorities
different approaches to heuristics and sandboxing.
different niches, one might find windows malware, one might find Mac malware.


Teaching Introduction to Information Security as a mandatory course I teach at an academic institute. We have decided to add a mandatory course: Introduction to Cyber Security.

We know that most of our graduates won't stay in academia, but will go to work in the industrial sector. Nevertheless, we believe that at least basic knowledge in information security is a must today.

The course's goal is not to make the students information security professionals, but rather to teach then the basics and expose them to this field.

Generally, we have two goals for this course:

Expose the students to the world of information security, and give them (again, most of them will go to the industry) useful tools and knowledge. The tools and knowledge should also be useful for graduates who do not work in the field of information security.
Encourage students to take also the advanced courses in this field.

Considering these goals, I have two questions for you, as we now have discussions about the content of the course.

Which subjects do you believe should be included in such a course? What are the most important concepts? Which topics are the most relevant for graduates that will work in the industry, but not in the field of information security? For example, topics like "Secure Coding" seem very relevant to every programmer, but this topic is less interesting in my opinion. Another topic that I considered is password management.
We have a special debate about SSL. I believe it is a must in such a course. Even if we choose not to teach about the specific algorithms, it is a must to know how this protocol works: What is a certificate, how to use it, which problems SSL solves, etc. Everyone uses this protocol, and I encountered many cases where knowledge of SSL was crucial. However, I was surprised to see that I have some opposition about this topic (SSL). I would like to hear your opinion--do you think SSL should be one of the topics?

Any other ideas and remarks are welcomed.

Additional details:

My course contains 13 meetings (units) of three (academic) hours each.
Units that I believe should be in the course, some of them following your great answers:

Introduction + CIA triad
Thinking like a hacker
OSINT
Scans (and relevant tools).
Firewall, IDS, IPS
Public and Private key shortly and SSL
Denial of Service
Network level - mainly DNS
Application level - two units with basic examples: SQL injection and maybe XSS (as second attack).
passwords management
Secure-Coding - with attention to mobile (and common mistakes).

I've been involved with this type of situation for the past several years. Here's what I teach and focus on.

For each topic. Lecture and technical details must be accompanied by either some kind of demo or some kind of hands on exercise. If the demo isn't flashy then it should be an exercise. This stuff is dense. I start every year with 30+ students in the club and end the year with much less. It can hard hard to keep interest. There's no reason for this to be boring when it is such an exciting topic.

Topics

CIA Triad. Basic concepts such as Authentication, Authorization, tokens, non-repudiation, privacy, security, vocabulary. Talk about the type of problem security is. Is it a technical problem...or a people problem? See what students think.
Thinking like a hacker. Ask them about vulnerabilities in the lunchline they go to or encounter in the bus systems or every day. Ask them to redesign their dining hall so students are unable to get cheaper lunches or whatever they come up with. It's honestly always really fun and gets them really interested in the things to come.
Physical Security. You don't have to spend a long time on this one in my opinion. Just make sure they know that if you have access to a computer, it is pretty much your computer.
Exposure to cryptography. This is a tough one to teach without diving in deep but you should show that basic building block technologies build secure protocols and understand the problems crypto doesn't solve. Usually I talk about the difference between public and private keys, I talk about establishing a shared key, and honestly just expose them to it. It really requires its own course but you can still talk about it.
Securing a computer. Passwords, Services, figure out what's running. What users exist, etc. Logging and Event viewing. I also talk about the tradeoffs with some security decisions you make. Log too much, you'll never look at them. Make the lockout policy too strict, you end up with a lot of angry users.
Malware. Talk about different types, show differences and real examples. Show them basic characteristics of malware and do super basic things to see what the malware is doing in a analysis environment. Capture network traffic it creates, ports it opens, things it install. Talk about the motivations of the attacker. This is also a good time to talk about the laws of your country (and the laws of your network admins) regarding hacking.
Web Security. XSS with real phishing emails, CSRF with real vulnerabilities, stored XSS with a real attack. This kind of stuff is EASY to demo to a roomful of students. It's really easy to whip up a toy web-app and show something. This year I wrote a vulnerable toy twitter and had the students use it. Next I tricked them into going to a different site I owned and I tweeted using their session. They were so amazed it was hilarious.
Basic steps a hacker MIGHT go through. Looking for targets, scanning for vulnerabilities, attacking the vulnerabilities, maintaining access. This is, surprisingly a difficult section to keep interest up on. Students are really amazed but lose attention quickly when they are sitting there with a meterpreter shell thinking "This is less exciting than I thought"
Buffer overflows and exploits. Toy C programs that behave badly and Metasploit are great for this

Have fun with it. It is such a huge amount of material that whatever you choose to do, as long as it is hands on, will be a lot of fun.


Is there a list of weak SSH ciphers? Is there a site, which provides a list of weak cipher suites for (Open-)SSH? I know for example that arcfour is not recommended, but there is a whole list of other cipher suites offered, where I am not quite sure.

On most systems, OpenSSH supports AES, ChaCha20, Blowfish, CAST128, IDEA, RC4, and 3DES. I am assuming you are talking about the symmetric ciphers used. If you are also wondering about the HMAC and key exchange, I can edit my answer to explain which of those are strong or weak as well.
The good
AES and ChaCha20 are the best ciphers currently supported. AES is the industry standard, and all key sizes (128, 192, and 256) are currently supported with a variety of modes (CTR, CBC, and GCM). ChaCha20 is a more modern cipher and is designed with a very high security margin. It is very fast. While AES is secure, the CBC mode leads to some potential vulnerabilities, so it is no longer recommended. CTR mode, or better GCM, would be preferred. ChaCha20 on the other hand is a stream cipher, so it does not use a block mode of operation and is therefore not able to use CBC insecurely. ChaCha20 additionally uses Poly1305 for authentication, making an HMAC unnecessary. Unlike an HMAC, Poly1305 does not rely on the assumption of security of any hashing algorithm. As long as the underlying cipher is secure, the authentication will be unbroken.
The bad
Blowfish, IDEA, and CAST128 are not bad ciphers per se, but they have a 64-bit block size. This means the key must be reseeded periodically. 3DES additionally, due to a meet-in-the-middle attack, has its effective security reduced from 168 bits to 112 bits. This is not horrible, but it is not ideal. The issue with 64-bit block sizes is described quite well on the Sweet32 website, describing the attacks made possible. The gist of it is that encrypting a large amount of data with a single key can leak information about the plaintext. When 32 GiB of data are encrypted, things get really bad. It's often recommended to change keys after every 4 GiB. While small block sizes are not great, OpenSSH does automatically reseed these ciphers more often than otherwise to attempt to mitigate this flaw. The ciphers themselves are not particularly bad. These ciphers, while old, are not subject to any known attacks that allow a complete break of the cipher. There are simply better alternatives out there.
The ugly
Arcfour, or RC4, is as you stated not particularly secure. Severe statistical biases have been known to exist for a while, and new attacks keep being discovered. While OpenSSH does drop the first 1536 problematic bytes of the cipher, it is still subject to a variety of other attacks. Avoid using RC4.
Overall, you should be using ChaCha20 or AES and avoiding RC4. Use 3DES only when necessary for backwards compatibility. The default OpenSSH settings on any modern installation should be fine in virtually all circumstances. You can't go wrong by using the defaults.


Does chatting over Skype expose my IP address? Is there a way to identify a person's IP address in Skype, when you're chatting with them? Does this depend on their Skype settings? And if you've recorded chat messages, can they lead to the actual person IP address, or their ISP's?

In general yes, there is ways of doing this, as a quick google search would've been able to tell you.

When ever you call, write or send a file to a person on skype you make direct contact with the persons IP/ISP IP, and that you are of course able to track. A simple way to do it in windows is using netstat -n while in a call, and look for the port you know you use skype on. A better way would be to use wireshark to monitor your traffic and look for skype protocols.

A quick youtube video on the simple way to do it:
http://www.youtube.com/watch?v=ro_zrbBsgBk

It is however very limited what kind of thread this might be to you. If you don't have any holes or open ports that shouldn't be open, or are hidden behind a basic router/firewall, it's quite a bit harder to get to you than just going through skype.


Security Headers for a web API I just got a setup, a golang web api behind a caddy server that has HTTPS by default via Let's Encrypt, the server proxies all requests to the web api. So I went around to test my webserver "security" on sites such as securityheaders.io. They gave me an F, so I added the headers they demanded and I got an A

Access-Control-Allow-Methods "GET, POST, OPTIONS"
Strict-Transport-Security "max-age=31536000;"
Content-Security-Policy "script-src 'self'"
X-XSS-Protection "1; mode=block"
X-Content-Type-Options "nosniff"
X-Frame-Options "DENY"
-Server

These are the headers I currently have, but I'd like to know if they are necessary for security when what I'm making is not a website but rather a API webserver, something like

Access-Control-Allow-Methods "GET, POST, OPTIONS"
-Server

So basically, all those security headers necessary if you want to just request your API?

Checking headers off a list is not the best technique to assert a site's security. Services like securityheaders.io can point you in the right direction but all they do is compare against a list of proposed settings without any context about your application. Consequently, some of the proposals wont't have any impact on the security of an API endpoint that serves nothing but JSON responses.

Strict-Transport-Security makes sense because it guarantees that users will directly connect to your site via HTTPS after their first visit and until the max-age timeout is reached - thereby preventing downgrade attacks. Even an API endpoint should be secured with SSL, so keep that header.
Access-Control-Allow-Methods: GET, POST, OPTIONS is not a security option per se. If your API works via CORS preflight requests you need to decide which methods you allow for cross-origin sites to use. Disabling CORS could make your API unavailable. If that particular setting is sensible depends on your implementation.
X-XSS-Protection: 1; mode=block can be good adivice for regular sites because it instructs the XSS Auditor (which is implemented in WebKit browsers but not Firefox) to not render the site when it detects a reflected XSS attempt. But for an API that just provides JSON responses and doesn't serve active content, this header doesn't bring any benefit.
X-Content-Type-Options: nosniff prevents browsers from making assumptions about the content type if the site didn't declare the type correctly. If you're running a JSON API you should serve the responses with Content-Type: application/json. If you do that correctly there will be no need to add the nosniff directive.
X-Frame-Options: Deny prevents any website from embedding your site in an HTML frame. That option stops clickjacking attacks where an attacker tricks users into interacting with your website through a disguised frame. But without interactive elements there is limited risk through cross-origin framing. Yet, as there are advanced attacks involving dragging content out of the frame which could disclose JSON responses, you might still want to leave that header there.
Content-Security-Policy headers control what kind of content from what origin your site is allowed to interact with  (scripts, stylesheets, images, etc.). Your setting "script-src 'self' means that only scripts from the same origin may be loaded. A CSP is useful for regular sites but doesn't make sense for your API endpoint because you don't serve any active content that could be controlled by the CSP.
The Server header specifies information about the server and the software running on it. It's often advised to not send that header at all to not disclose anything about backend software and versions.


How to gain root privilege after injecting code using a buffer overflow vulnerability? Once the attacker finds an exploitable vulnerability in a user program, e.g., buffer overflow. Assume his goal is to gain root privilege and typical countermeasures are not present in the system (ASLR, NX, etc.).

What are the general ways that an attacker can gain root privilege (in linux and windows)?

EDIT 1: A simple and real examples would be really helpful.

There are many ways to get to root. You need to consider exploits which get you root, as well as those which get you access at a lower privilege in conjunction with a privilege escalation exploit.

Generally what you need is an exploit in a service run as root, or another privileged account.

As cremefraiche noted, you should have a good read of cve.mitre.org to get some idea of the variety.


Does HTTPS encrypt metadata? Does HTTPS encrypt metadata?

Not Necessarily what is on the page, or ads or anything like that, but it is possible for someone else to know metadata i.e what the tab is called or just the website name?

Does HTTPS encrypt metadata?

TLS will only encrypt the payload. Notably the following meta data are still available in clear:

Layer 3/4 information, notably source and destination IP/port of the connection: This can be used to get information about the client, i.e. the network where the client comes from. Additional information like TTL, initial sequence numbers, initial window size can be used for passive fingerprinting to detect the OS. And the target IP can be used to get information about the server, i.e. what the client is visiting.
The target domain name if SNI is used: SNI is used by all modern TLS stacks at least for HTTPS. This can be used to further determine the target of the clients connection.
Cipher suites and extensions offered by the client: This can be used to fingerprint the client, i.e. detect which kind of browser and maybe OS version is used.
The servers certificate: this adds some more information  about the target of the connection and often provides the exact domain name even if SNI is not used (like in non-HTTTPS connections).
The optional client certificate: since this might be used for authentication it adds some useful information about the client.
Size and timing of the transferred data: While the exact size might not be available when looking at the encrypted data the approximate size can be determined. Together with timing and direction of transfer (i.e. traffic flow) this can be used to find out which protocol might be spoken (HTTP, SMTP, VPN...) because different protocols have different flow characteristics. If used on HTTPS only on a target site with unrestricted access it might even be possible to narrow down which of the public available pages on the site the client has visited.