Is it possible to use a GPG or SSH key for web based authentication in a secure fashion? Let's say hypothetically I am writing a web application targeting technically inclined, security-conscious users who have no problems generating and using GPG or SSH keys.

Is it possible to use said keys to authenticate with a web application in a secure fashion to replace traditional password-based authentication?

If it is possible, what will the authentication steps look like? Is there perhaps a known good implementation of such an idea for popular languages and platforms like Ruby, .NET, Java or Python?

If it isn't possible, what are the reasons? Is there perhaps a constraint on web browsers accessing the GPG keychain or SSH key file?

For a Web application, the main problem is that the Web site code (Javascript in a browser) is not able to read and write files at will. Well, in general, this is more a boon that a problem, but here it means that the Javascript code will not be able to access SSH or PGP private keys.

There are things which can be done, depending on how much technology-savvy your users are, and how many manual operations they will tolerate:

You could use a locally installed browser extension which accesses the SSH or PGP private keys on behalf of the Web site. Preferably, some user control is advisable: we really don't want a browser which will sign things just because a Web site said to do it.
The server may act as a SSH server, and requires clients to connect with SSH and key-based client authentication. The user would run SSH in "SOCKS proxy" mode. The Web server itself would listen only to localhost, i.e. be unreachable except through such a local proxy. In this mode, the Web server could even be HTTP, not HTTPS; this would really be replacing SSL with SSH. On the server side, keeping track of users should use mod_ident or something similar (the SSH server knows who the client is, but the information must be forwarded to the HTTP server; fortunately, this is on the same machine, so the Unix-level identity can be used).
The Web site could display a "challenge" as a downloadable file with random contents. The user obtains the file, signs it with GnuPG, and pastes the (ASCII-armored) output into a text field on the Web site. The server verifies the signature, and accepts it as authenticating the user (provided that the server already knows the user's public key). Clunky, but works.

A mail-based variant of the above can be advisable, because PGP implementations are often embedded in email software, and also because it opens a possibility of not having to trust an external root CA. It would look like this:

User connects to the Web server with HTTPS. The server uses a self-signed certificate. The browser warns about it (the "red scary warning") but allows the user to proceed.
In the site, the user enters his name. Then the server sends a signed and encrypted email (with PGP) to the user; the signed email contains a random nonce, and also a copy of the server's SSL certificate thumbprint. The random nonce is also printed out on the Web site itself.
The user verifies the PGP signature on the server's email, then checks that the thumbprint matches the one he can see from his browser; this convinces the user that he is seeing the genuine server certificate, so there is no ongoing Man-in-the-Middle attack. (This is where we replace the X.509 CA system with PGP-based validation.)
The user also verifies that the nonce displayed on the Web site matches the one he sees in the email (this is important).
The user responds to the email by sending its contents back, this time signed with his own PGP private key, and encrypted with the server's public key. The server verifies that email and thus knows that the nonce value was indeed received by the intended user.
The server sends the nonce value as a cookie to the user's browser. This allows browsing without pestering the user with further authentication rounds. It is up to the server to decide how long it will accept the cookie as a valid authentication token.

In the above scheme, it is important to notice that by sending back his email response, the user is really authorizing the server to assume that whoever comes back with the nonce (as included in the email) is really the user himself. This is why manually checking that the nonce matches what is shown on the Web page is important.


Symmetric encryption for data protection My team is working on a solution to store sensitive information on a remote storage solution.  I am proposing that we use symmetric encryption of the data where there is a unique key per document.  The keys for this will be stored such that it is accessible to where the data will be used but separate from the encrypted data.  Encrypted data will be written to and read from the storage.  While this is possibly overkill, I think it will ease some of the concerns that are hampering the adoption of this technology.  The idea is that even if something goes wrong and someone gains access to the document storage, the data will not be useful without access to the keys.  In the event someone has access to these keys, these documents will be the least of our concerns.

In a nutshell, the concern here is that someone can access this data from basically anywhere and retrieve documents through interactions with that storage provider alone.  The proposed solution is intended to make it such that even if an attacker were to gain full, authenticated access to the document store, they would not have enough information to get the content of the documents.  The would need to access to information that is not available at that storage provider.  This (in theory) makes the security of this data basically no worse than the current situation.  This might be a questionable goal but the problem I have is largely political.

I should also add that this is not meant to be the only security for these documents.  This would be auxiliary to out-of-the-box protections.  A side question would be whether there is anything about this that could weaken those standard approaches.

After doing some reading, I think using 256 AES should be adequate.  Is this the case and for how long should we expect this to be good enough?

I also understand that using a MAC is standard to ensure that the data has not been corrupted.  After reading the wiki page here and then delving into more detail and some debate, I'm struggling to make sense of this in this use case.  Data corruption is not a primary concern here but I don't think it hurts.  But if all I want to do is verify the message has not been corrupted, is there any reason a hash (e.g. SHA-256) stored with my key wouldn't meet my requirement?  I'm probably missing something here.

Does the overall approach and algorithm seem legit?  Any help with the MAC/hash stuff is appreciated.

After doing some reading, I think using 256 AES should be adequate. Is this the case and for how long should we expect this to be good enough?

Yes! AES-256 is a widely used and standardized algorithm. The one cavaet is AES-256 is not in itself, the entire algorithm. The algorithm requires you to specify a block-cipher mode which is the mechanism in which it distorts the blocks of data before encryption to avoid patterns emerging. I recommend a look at this image. The most common block cipher mode is CBC and it is ideal for encrypting data that is more than one block in length (more than 128 bits which from my understanding, your data will be).

Properly configured AES-256 should be secure well into the future of computing. Symmetric encryption is currently believed to be secure even in a post-quantum world (unlike asymmetric cryptography such as RSA which will most likely crumble) so you should sleep well at night knowing your data is secure well into the future.

  But if all I want to do is verify the message has not been corrupted, is there any reason a hash (e.g. SHA-256) stored with my key wouldn't meet my requirement? I'm probably missing something here.

The key difference between traditional cryptographic (collision-resistant) hash functions such as SHA-256 and HMAC functions is the HMAC hash functions are "keyed" meaning they require a secret key. HMAC-SHA256 (as an example) is often used in cases where there is reason to believe an attacker may try to manipulate data and re-calculate the hash to make the system appear to be un-altered.

Let's say I have a text file that contains instructions on when to launch an attack and a second file to contain the SHA-256 hash of the first. I write to the file "attack at dawn" and hash it with SHA-256 and logout. The attacker now logs in (through means out of scope to discuss how here, this is a simple example) and the attacker edits the text file to say "Do not attack!". But now the SHA-256 hash won't match, so the attacker re-calculates the SHA-256 hash of the file he edited and replaces my old hash. Now I send this file and its hash to my generals. They hash the file and see it matches (and therefore trust it) and see "Do not attack!".

In walks the HMAC family. In the same example if I used HMAC-SHA256 to hash my file, it would require my secret key to complete the operation. Therefore, when the attacker edited my text file he does not know my secret key and fails to generate a valid HMAC-SHA256 of the edited file. When it is sent to the generals (they too have my secret key, either through pre-distribution or PKI) they generate the hash with HMAC-SHA256 and they do not match. They know the message has been tampered with.

Long story short: SHA-256 is a great way to validate non-malicious data corruption did not occur as it is collision resistant but anybody can calculate a SHA-256 hash. If your threat model includes the possibility of malicious tampering by an attacking party, using HMAC-SHA256 hash with a secret key can ensure the attacker cannot manipulate the data and re-create the hash to make it appear un-altered.


Can exploit vulnerability if program started with gdb, but segfaults if started without gdb I'm currently trying to exploit a simple program called basic_vuln.c

#include <stdio.h>;
int main(int argc, char** argv) {
  char buf[64];
  strcpy(buf, argv[1]);
}

I'm using xubuntu 12.10 with 3.5.0-17 Linux Kernel, ASLR turned off and compiled with the current version of tiny c compiler.

Now to the actual problem, I'm injecting a basic shellcode which spawns /bin/sh.
The problem is that when I execute it within gdb, everything works fine and I get a shell. But if I start the program within bash I get a segfault.

I tried to get a core dump to see where the problem lies, but I guess because of the corrupt memory I don't get any (if I don't give the program any arguments, it segfaults and I get a core dump).

Any ideas? If you require more details on the system like gdb version or similar, I'll post it as fast as I can after request.

This will almost always happen. When you load a program into gdb, things get shifted around a bit - not much, but enough to make an address overwrite wrong.

You have a couple of options, you can use tools (such as metasploit's pattern_create.rb) to determine the actual address of your buffer in memory when the program is run outside the debugger. This is achieved simply by passing a non-repeating pattern to your program, and seeing at which address the segfault occurs (core dump), that way you can determine how far into your buffer lies the section that is written into the return address. ignore my rambling, this is completely unrelated, go with the nop sled

Or you can just extend your NOP sled a little and start guessing addresses. It usually doesn't take more than a dozen or so attempts on a small program.


Where is Bash Shellshock vulnerability in source code? I have been hearing about the Bash Shellshock problem since yesterday and am curious to see where in the source code this problem occurs. I have downloaded the source for Bash 4.2 from here.

Where exactly should I look for Shellshock in the source code of Bash 4.2?

I was able to find this patch information for 4.2 (from this page), but still if someone could explain clearly where Shellshock occurs, it would be helpful.

CVE-2014-6271

CVE-2014-6271 was the first vulnerability discovered. A patch can be found here.

From Wikipedia:

  Function definitions are exported by encoding them within the
  environment variable list as variables whose values begin with
  parentheses ("()") followed by a function definition. The new instance
  of Bash, upon starting, scans its environment variable list for values
  in this format and converts them back into internal functions.

  Bash performs this conversion by creating a fragment of code that
  defines the function and executing it, but it does not verify that the
  fragment is merely a function definition. Therefore anyone who can
  cause Bash to execute with a particular name/value pair in its
  environment, can also execute arbitrary commands by appending those
  commands to an exported function definition.

In the source code, we can see the importing of the function variables in variables.c:

/* Initialize the shell variables from the current environment.
   If PRIVMODE is nonzero, don't import functions from ENV or
   parse $SHELLOPTS. */
void
initialize_shell_variables (env, privmode)
     char **env;
     int privmode;
{
  [...]
  for (string_index = 0; string = env[string_index++]; )
    {

      [...]
      /* If exported function, define it now.  Don't import functions from
     the environment in privileged mode. */
      if (privmode == 0 && read_but_dont_execute == 0 && STREQN ("() {", string, 4))
      {
        [...]
        parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST);
        [...]
      }
}

We can see a for loop over all the environment variables given to the function, and then an if about whether we are in privileged mode, but that is disabled most times.
The "not verify that the fragment is merely a function definition" part is in the parse_and_execute line. The function description from builtins/evalstring.c:

/* Parse and execute the commands in STRING.  Returns whatever
   execute_command () returns.  This frees STRING.  FLAGS is a
   flags word; look in common.h for the possible values.  Actions
   are:
    (flags & SEVAL_NONINT) -> interactive = 0;
    (flags & SEVAL_INTERACT) -> interactive = 1;
    (flags & SEVAL_NOHIST) -> call bash_history_disable ()
    (flags & SEVAL_NOFREE) -> don't free STRING when finished
    (flags & SEVAL_RESETLINE) -> reset line_number to 1
*/
int
parse_and_execute (string, from_file, flags)
     char *string;
     const char *from_file;
     int flags;
{

So everything that's passed to the function gets executed as if it would be an ordinary bash command. The flags SEVAL_NONINT and SEVAL_NOHIST are self-explanatory (explanation of interactivity, NOHIST doesn't add the definition to your bash history) don't prevent passing other things than function definitions. The patch introduces flags SEVAL_FUNCDEF and SEVAL_ONECMD that can be passed in the flags field to parse_and_execute:

+ #define SEVAL_FUNCDEF 0x080       /* only allow function definitions */
+ #define SEVAL_ONECMD  0x100       /* only allow a single command */

The patch also adds functionality to parse_and_execute to comply with those new flags, and changes the call to parse_and_execute to pass those flags:

-     parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST);
+     /* Don't import function names that are invalid identifiers from the
+        environment. */
+     if (legal_identifier (name))
+       parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD);

CVE-2014-7169

CVE-2014-7169 bases on a function parsing issue that has been pointed out by Tavis Ormandy. The fix of parse.y seems very simple, but its trickier than CVE-2014-6271:

/* Called from shell.c when Control-C is typed at top level.  Or
   by the error rule at top level. */
void
reset_parser ()
  [...]
  FREE (word_desc_to_read);
  word_desc_to_read = (WORD_DESC *)NULL;
+ eol_ungetc_lookahead = 0;
+
  current_token = '\n'; /* XXX */
  last_read_token = '\n';
  token_to_read = '\n';

The eol_ungetc_lookahead variable is explained at its definition:

/* This implements one-character lookahead/lookbehind across physical input
   lines, to avoid something being lost because it's pushed back with
   shell_ungetc when we're at the start of a line. */
static int eol_ungetc_lookahead = 0;

Its read inside the shell_getc function, and if its set, its (one-character) content is read instead.

The command rm echo; env -i X='() { function a .>\' bash -c 'echo date'; cat echo first creates a syntax error with the . character (you can also use other characters here, like a or =), and then uses the insufficient cleanup of the eol_ungetc_lookahead variable in the reset_parser function to inject the > character into the 'echo date' string that's also given to bash. Its equivalent to rm echo; bash -c '> echo date'; cat echo.

Further resources on the oss-sec mailing list.


Security of Cloud Storage What are the main security risks of popular cloud storage services such as Dropbox? I am torn between the convenience of cloud storage and the potential security risk of it. How can I evaluate whether a particular service meets my security requirements?

No. The biggest risk I fear is some government closing down the service because of suspected illegal use, taking all disks for analysis and leaving me as sincere user without my file backups. eg. Megaupload (Megabackup)


Sniff API request through proxy I have an iOS application that consumes an API. That application sucks so I was trying to "discover" that API and make my own application consuming that API.

The issue is that the API is under SSL/TSL so I tried using Wireshark with naturally, no luck since the URL is hidden due to SSL.

Is it possible to set up a proxy WIFI server, make my phone trust that proxy and try to get the traffic decrypted on that proxy server ?

I'm kinda new to all this of packet sniffing and network auditing, so I'm trying to come up with some ideas.

Thanks!

Yes, by using an intercepting proxy such as BurpSuite (https://portswigger.net/burp/).  When you setup your device to use that machine as a proxy; you can surf to "http://burp" to download the CA certificate.  This prevents you from having to do all that yourself.

When you import and install that cert, you can see the decrypted HTTPS traffic that is passing through your proxy; that is - unless the apps you're looking at perform any form of certificate pinning; then they'll stop working.


Securely analyze and format a USB flash drive I need to scan the contents of a USB stick with several antivirus software. I have several ways to do this.

Either I mount the key, I scan its contents (I may place the suspicious files in quarantine), I copy the files on the host, I format the key and I copy the files to the key. This solution is super slow and is the worst solution.

I'm thinking more of a solution that mounts the key, copies the files one by one in a sandbox, each new file that arrives (FIFO stack) is scanned (possibly placed in quarantine) and once the whole copy and analysis of the key content is complete, I format the key and copy the healthy files in the other direction. What do you think in terms of security? Do you have another solution in mind?

Thank you for your help

Assuming that the USB flash drive is in fact just a flash drive:

Do a Physical Image of the device without ever mounting it.

Analyse the Image on an isolated machine or sandbox.

You don't say why you are dong this, but the above method allows analysis of unallocated and slack space that your file copy approach will not.

If this is for more than your own use in an attempt to clean up, such as for legal action, there are additional steps necessary.

       ----------- edit response to comment ---------

"The goal of the operation is to build a usb cleaner station"

Since you are not interested in unallocated space or performing an analysis as stated, but rather a standard virus scan and clean, why do you feel you need to perform a format and repopulate? Most similar systems I've dealt with consist of a standalone workstation with multiple virus scanners that run against the inserted media. Simply deleting, or overwriting if concerned, detected malware is no different than not finding it in unallocated space in the first place.

Note also that formatting and repopulating can create its own problems. It will disable bootable devices. It may also disable DRM files dependent upon time stamps.

Also, there may be multiple file formats. Within plain Windows 10, you may encounter: NTFS, FAT16, FAT32, or exFAT.There may even be multiple partitions.

I'd suggest that any reformatting be punted to the user/owner of the media after providing scan results.


Ways to impress children about web privacy violations and concerns I would like to make a simple lesson to some children about the bad web surfing consequences for their privacy and personal data leaks.

E.g. privacy issues by using social networks, visiting websites full of ads, etc...

I have already written some text about those issues with today's privacy violations from websites, but I want to show them some impressive and practical things, also showing some technical stuff could be useful to obtain attention.

I have made some screenshots using Firefox Lightbeam extension that show some interesting things about third parties cookies data sharing between websites.

Any other website that show interesting and impressive things about websites privacy violations and personal data leaking?

E.g.
Is there any site that I can use to show a child that use Facebook or others that his/her personal informations or photos are online or shared or gathered by other websites.
I'm open to any useful stuff.

Thanks a lot.

Here is an interesting article about a teacher showing the dangers of posting images on social networking sites. May be worth doing your own experiment.

You could also use BeEF to demonstrate some client side attacks. This would be interesting to put the hook in malicious ad JavaScript. Hope this helps, good luck!

Additionally, there is a pretty cool website What Every Browser Knows About You.


What about SSL makes it resistant to man-in-the-middle attacks? Here's how I understand what SSL certificates actually do, in 4-year-old-child terms. There need to be three parties involved. Two parties are just my client, and the server I'm communicating with, while the third is the certificate issuer. My client will ask the certificate issuer if the server I contacted is really the server it says it is, the certificate issuer will propose a challenge to the server, and respond to me if it went well.

Here's the thing though. When I searched for other people asking about man-in-the-middle attacks, answers said it would only be possible if the third party (the certificate holder issuer) got its private key stolen, which the man in the middle could use to fake its identity by completing the challenge, or something like that...

However, without stealing the private key, and without stealing anything -- if the man in the middle can impose as the server of the site I'm trying to reach (simply by redirecting its domain name to its own IP), then what's stopping it from doing the same with the certificate issuer's server? So for example, it could redirect Facebook's IP address to its own server to try to get me to enter my account credentials, and when my browser tries to ask Digicert (the certificate holder for facebook.com) whether I'm communicating with the authentic Facebook server, the man in the middle could also redirect Digicert's IP address to itself again, and wrongly confirm to me that Facebook really is Facebook.

My client will ask the certificate issuer if the server I contacted is really the server it says it is, the certificate issuer will propose a challenge to the server, and respond to me if it went well.

No, you don't have to separately contact the issuer to verify a certficiate. Otherwise you would just be shifting the trust problem. Instead there has to be a local trust anchor.

That's why your browser (and eventually your OS) already comes with pre-installed certificates for certificate authorities that were deemed to be trustworthy. From the Mozilla CA Certificate Policy:

  When distributing binary and source code versions of Firefox, Thunderbird, and other Mozilla-related software products, Mozilla may include with such software a default set of X.509v3 certificates for various Certification Authorities (CAs). The certificates included by default have their "trust bits" set for various purposes, so that the software in question can use the CA certificates to verify certificates for SSL servers and S/MIME email users without having to ask users for further permission or information.

When your browser establishes an SSL connection to facebook.com, the server presents the certificate along with a signature to prove that this certificate was issued by DigiCert for the domain facebook.com. The browser checks this by verifying that the certificate is transitively signed by DigiCert's root certificate that came with the browser. If the corresponding root certificate can't be found or isn't trusted, then there is no valid certificate chain and the verification fails.

As an additional security mechanism Facebook uses the HTTP Public Key Pinning (HPKP) feature which stops a man-in-the-middle attacker even if they managed to compromise a CA and generate seemingly valid certificates:

  The feature binds a set of hashes public keys to a domain name such that when connecting to a site using TLS the browser ensures that there is an intersection between the public keys in the computed trust chain and the set of fingerprints associated with that domain. This check is done during the certificate verification phase of the connection, before any data is sent or processed by the browser.

(Source)

While any website can announce their own pins via a Public-Key-Pins header that will become active after your browser's first visit (TOFU model), Facebook and some other high-profile sites have their pins built-in in Firefox and Chrome, meaning that these browsers trust Facebook's certificates directly and don't need to check with the DigiCert root at all.

Also note that there are independent mechanisms where clients do actually contact a CA directly. For example, your browser can use OCSP to check a particular certificate's revocation status.

Also see:

How are Chrome and Firefox validating SSL certificates?
What is an SSL certificate intended to prove, and how does it do it?
How are SSL certificates verified?


Why are SSL certificates an annual expense? I understand SSL certificates cost money because of reputation: most/all web browsers have a limited list of companies that demonstrated they are trusted sources of SSL certificates and therefore don't present users with a Back To Safety! screen for those companies' products.

My question is why is this not a one-time expense?  I am considering moving from a self-signed cert, but my web host just told me it would be starting at $35 per year, and they can easily go up to hundreds per year.  Why isn't this a one-time fee?

Let's start with the cynical view:

Certificate Authorities are for-profit companies, so they will charge as much as they are able to get away with!

More seriously, running a certificate authority is an expensive, low profit margin business, but the answer really comes down to the type of certificate you want.

Domain-Validated (DV) Certificates

For a basic DV cert which, makes your browser address bar look like this:

the costs are very low - basically the CA just needs to confirm that the person requesting the cert had control of the server at the time of request. This can be fully automated. As @SteffenUllrich points out, in 2014 the Electronic Frontier Foundation, Mozilla, and the University of Michigan teamed up to set up a 100% free CA Let's Encrypt for issueing DV certs. Based on the use-case you described in the question, it sounds like that would suit your needs.

Extended Validation (EV) Certificates

If you want the high-end certs that include your verified company name and country in which it is registered to appear in the browser like this:

then there is significantly more cost to the CA. Before issuing an EV cert, the CA is required to have a human verify a whole pile of things about the legal status of your company. Things like: is your company legally registered under the name listed in the cert request? Is the person requesting the cert listed as a legal officer of the company in the company's registration documents? Is the DNS record for the requested website registered to the same company? etc.

Why a recurring fee?

The reason that CAs charge a recurring fee is the same reason that you can't get a 10 year SSL cert: the CA/Browser forum requires certs to expire and be completely re-validated every year or two. The security reasons for this are to force key rollover, to prevent the company from going bankrupt or changing name and a rogue sysadmin from  continuing to use the cert nefariously, etc.

The CA is required to do all this background checking not only on first time issuance, but also every time the cert is renewed. The added value for you is that your customers get a higher level of assurance in the trust-worthiness of your website (sure, 99% of consumers won't notice, but auditors and hackers certainly will!), and also, Google is moving towards giving higher search preference to sites with higher quality certs.

This is why certs can cost hundreds of dollars per year; you are not just paying for a couple bits of data, you are paying for the time of the human who has to do the verification.

OCSP servers

There are also server costs for maintaining a cert, mainly the costs of OCSP, which requires the CA to maintain high-bandwidth, low-latency, zero-downtime servers for responding to revocation checks on each cert they issued. While this might not sound expensive, every web browser must ping a CA's OCSP server during every HTTPS page load. Every extra millisecond that the CA takes to respond adds to the page load time of every page on the internet. Running a low-latency server at this level of traffic is a tricky network engineering problem.

[disclosure: I work for a CA]


ASLR does not seem to randomize text section I wanted to make some basic tests on Linux ASLR, so i wrote the following code :

#include <stdio.h>

void funct(){
    int a= 0;
}

void main(){
    int b=0;
    printf("funct : %p\n", &funct);
    printf("var stack : %p\n", &b);
}

When I run this code, the second pointer (which points to a value on the stack) seems randomized as it changes from one execution to another, but not the first pointer.

I tried compiling with -fPIC gcc option, but it doesn't work either.

Also, I already checked that /proc/sys/kernel/randomize_va_space is equal to 2.

Could someone explain what I'm doing wrong ?

The text segment is not typically randomized in ASLR implementations, and this is why Return-Oriented Programming (ROP) chains work.   The idea is that the application's own code should be 'safe',  so randomizing this memory space would be a waste of resources.

ROP chains are about building a malicious payload using the application's own functionality.  A good analogy is that you can take any well meaning sentence,  and make it an insult by choosing specific letters or words to make a new meaning.


Does a CAA record on a local hostname in a LAN offer additional security? A CAA DNS record limits the certificate authorities that may issue a certificate for a domain and its subdomains. Do CAA records make sense in a LAN environment? Assume internal hostnames such as ldap.emea.contoso.local, with certificates signed by an internal CA. Can a CAA record on contoso.local enforce that only the official Contoso CA can sign a certificate for Contoso domains?

Using CAA DNS records for internal networks doesn't really make sense, especially when you're using a .local domain.

Simply put: The way CAA records work is that an issuing CA will check the CAA records of a domain through public DNS records but only if the issuing CA is told to do so.

Public CAS are required to do that. But a public certificate authority cannot issue to a .local domain anyway since domain control is not verifiable.

Someone who set up an internal CA however could still issue to your contoso.local domain since his CA would not have to be configured to check public CAA records.

Hope that helps!


How hash ensure integrity of data? I understand what a hash is, basically we calculate a hash and append it to the message and send it to the receiver. If someone alters the message, the receiver will know because there would be a different hash value.

Since hash algorithms are well-known such as MD5, SHA1, if there is a man in the middle attack, can he then alter the message and regenerate the hash based on the altered message and send it to the receiver? The receiver will not know it is an altered message by calculating the hash, correct?

Yes, that's correct. That's why if you're using a hash for data integrity then you must deliver the hash by separate means (eg. posting the hash with your twitter account). To get around this problem in emails, rather than using a hash you can use public key cryptography that allows the receiver (and anyone else) to verify the signature using your public key, but the signature cannot be created without your private key. This is what PGP uses.


How to enter sensitive information securely? I'm interested in finding out what is the best method to enter sensitive information somewhere given an insecure computer.

Granted, I know that if the computer has a keylogger or some other malware that captures input, there are much more important things that I should worry about (for example what I am searching up on google, don't want those pesky hackers to know that I'm looking up cute dog photos).

But what if I am logging in on a school computer that has something like LanSchool so that instructors may monitor our computer activity? What if I am visiting an Internet/cyber café?

I have heard that on-screen keyboards (such as the one given by lastpass) will bypass keyloggers. But I'm paranoid, an attacker might use my cursor position every time I click to deduce what key I press.

Given that I have a keylogger, what are effective ways I can use to input sensitive information on say, a web form or a client app?

(Note: please avoid answering "do not use that computer" because I already know that if I want to avoid compromising my information, I should not use a compromised computer)

To simply put, there isn't any "one true secure method".

Why, you might ask? Because computing has always been about trust, whether implicit or explicit.

Regardless if it was the 1960's or today, you trust the machine in question to act like you expect. This can prove quite an issue, because potentially, you could be dealing with a software or hardware based keylogger, to a whole virtualized OS, which would have access to all the memory contents at any give time.

There's no way a user could traverse a massive list every time they sat down at a computer. Somethings are simply impossible, such as verifying firmware on one of the many chips placed into the computing device.

The key part to understand is how much trust do I require? For some corporations and government agencies, this could be down to the firmware level, and expense isn't an issue. To a home user this could be software based keyloggers, and malware. To a researcher, it could prove to be "none" as they only expect to see a correct output from a simulation.

The sophistication of the attack vector(s) in question are important, which is good to see you mentioned a school environment.

It's common to see "monitoring tools" in school computer labs for whatever reason the IT staff, librarian, principal, and/or school board sees fit. You can search the internet for common software, but most do include a software keylogger, hooks to the Windows API to retrieve all gui window titles, and take periodic screenshots.

An on-screen keyboard is sufficient to guard against a spying librarian, as I remember back from my high school days. I even remember writing a program in Autoit to change the title of all active windows I had open to fool the monitoring software (that was from my mischievous days). The software my school used is linked below.

A software keylogger and typical "off the shelf" monitoring software isn't going to log where you click on a screen, it's too much effort. Keepass with it's entry obfuscation can even deter spying users that deploy software keyloggers.

Web Links:

http://keepass.info/

http://www.netsupportschool.com/


Did scammers take control of a subdomain to host phishing site? This morning I received a text message (ostensibly) from my bank:

  We need to contact you. Please visit https://paymentassistance.nationwide.co.uk for more information

My spidey sense immediately tingled. I've never received an SMS from my bank before, and when they email me they always use my name and post code. However nationwide.co.uk is the correct domain for my bank. Out of curiosity (and with a healthy scepticism) I typed the URL on my computer.

Is it a phishing site?

It uses the same theme and colours as the familiar website http://www.nationwide.co.uk
It has a https URL (certificate from Symantec)
It has links to the familiar website in its footer, but its own version of the 'contact us' page with an alternate phone number 0800 464 3050. Compare https://paymentassistance.nationwide.co.uk/doc/contactUs with http://www.nationwide.co.uk/support/contact-us/call-us#xtab:credit-cards
That phone number only appears on that page and not on the familiar website or elesewhere on the web. It differs from the number printed on my card (0800 055 66 11)
The form asks for your name, address and last four digits of your credit card number (not the whole thing)
If you try to login (I used made up data) it fails and asks you to phone them (on the suspicious number)
If you phone the number a recording answers "Welcome to Nationwide credit card services. Your call may be recorded for quality and training purposes."
The recording then asks for all 16 digits of your credit card number.
After entering a made-up 16 digit number, a friendly lady calling herself Kelly answered the phone. I hung up.

If this is phishing, I don't understand:

How did scammers take control of a subdomain? Have they hacked Nationwide's computers? (DNS servers?)
How did they get an SSL certificate for it?

It looks like this page has been running since at least January 2014:

http://www.unknownphone.com/search.php?num=02033222992
http://www.cookham.com/cookhamnow/bustrain/police/crime20140129.htm
https://twitter.com/sophielambrakis/status/464730297838604288

The Twitter user asked the bank about it, but they didn't reply.

By the looks of things, assuming that the link you've provided is correct, they didn't.

By using the Nationwide website (as accessed by typing in the domain name manually, to preclude any similar character attacks), and using the search function (http://www.nationwide.co.uk/search?term=payment%20assistance), that subdomain showed up in the list of results.

The link for the second result is https://paymentassistance.nationwide.co.uk/

The general approach when it comes to things like this is to do this - search and check that the address you are using is correct (if you have paperwork from the organisation with the address on, even better). Type it in, rather than following the link, just in case. If they have a search engine, look for whatever is suspicious, and if it turns up, chances are, it's legitimate. You can also try phoning them, or popping into your local branch, in the case of a bank, to verify this.

Additional informationI contacted Nationwide via their online banking contact section, and got the following response:

  Completely understand how this could cause you some concern.

  Don't worry, this is a genuine Nationwide website.  This is from our Credit Card Services as they're most likely wanting to double check a payment with you.  It's completely safe for you to go ahead and complete this.

  If you're a little uneasy about completing this online, please can I ask that you give our Credit Card Services a call directly.

If you are still concerned, I suggest contacting then in this way!


Masking password when typing vs hiding input when typing There is a command-line application that interactively prompts you for your password to a third-party service.  Whereas e.g. sudo completely hides your input as you type your password, this application prints * for each character you type.

For a command-line application, does the act of masking a password pose any more security risks than completely hiding input?  In other words, would there be any compelling security-related reason to refactor this application to hide input?

sudo does not hide input completely because of an alleged security benefit, but because it is much simpler to do in the context of a Unix terminal. A Unix command-line application normally receives user input by whole lines (nothing is sent to the application code until you press the "Enter" key); hiding the input is only a matter of telling the terminal not to display the typed characters, with a tcsetattr() call (e.g. see this answer). To display stars for each entered character, sudo would have to do some more complicated things, i.e. set the terminal in "raw" or "cbreak" mode (see this page for some details); sudo would then have to implement line-editing itself (handling of backspace key, or Ctrl-U to clear the complete input, for instance).

Although completely hiding the input hides the password length, this information is still available to bystanders, who can use their ears instead of their eyes: instead of counting the stars on the screen, they can count the key presses. Therefore, the alleged security benefit of complete hiding would be, at best, very slight.

Displaying the stars makes a much better user experience, in particular people with slightly flaky keyboards, where a keypress can be "lost", or else involuntarily duplicated.


Could a dynamic security system prevent DDoS attacks? I don't know much about security, but here's what I think I understand about my question, at a high level:

DDoS attacks are caused by a LOT of network traffic, which can be hard to mitigate because you can't anticipate where they're coming from.
One method of two-factor authentication is to set up a trusted connection to a synchronized system that dynamically generates a security token.
During a recent DDoS attack on my favorite MMO, one of my friends made a comment about "the only thing they can do is change ports and hope the attackers don't pick up the change for a while".

So, one question is: is it an accurate assumption that it would be hard to keep up a DDoS attack if the provider kept changing the ports that it expects data to come into?  This seems reasonable to me.

And the second question is: if so, are there any drawbacks to using some kind of synchronized system to change the ports every so often, to make it harder for the DDoS attack to persist?  So, if you have a trusted client, you would have "your current port" to talk to, and when it's time to change, your client would know to make the change.

Like I said, I don't know enough to know all the (I'm sure) massive flaws in my question, but this doesn't seem like something that would have a crazy performance hit, and it seems like a good way to keep attackers out of your system.

It really depends on the type of attack that your target is dealing with, however the solution you presented while very creative, doesn't solve the problem unless you have an unskilled attacker who only uses application attacks

Types of Attacks (and how to stop them):

A volumetric attack sends a large amount of raw traffic to saturate the network's uplink taking the entire server offline.

Solutions to block volumetric attacks are pretty much limited to Cloud "scrubbing centers" which utilize advanced rulesets to choose which traffic to forward to a server and which to discard, these "scrubbing centers" are only possible because they have an insane amount of hardware and available bandwidth topping multiple Tbps of capacity.

An application attack sends a small amount of specialized traffic to target the running application, for example you could send let's say 10,000 HTTP requests per second to a web server to crash it making the website unavailable.

Solutions to block application attacks have a larger variety, realistically rate limit the functions in your application, if a single IP is hitting the limit too often, automatically issue a firewall rule to block further requests to the application.

A few things to consider

2-factor cannot mitigate DDoS Attacks, it's a nice security tool, but it's not very effective in blocking DDoS Attacks.
The main drawback would be constant disconnects and reconnects ruining the fun of your game server. Sure you could keep changing the port to prevent an application attack, but you would go down and stay down the moment your attacker switched to a volumetric attack.

A more practical solution

I would switch to a server provider who offers to filter very large attacks. Some providers include Voxality, OVH, and DDoS-Guard.net (they protect datacenters, you normally wouldn't buy from them directly, Blazingfast uses them for added filtering). From there you only have to deal with application attacks if not filtered by the provider. It's going to save you a lot of headache, the gamer community will only be targeted more and more by DDoS Attacks, you should be prepared to be under constant attack.


Protecting an admin area from the public We are about a month away from launching a pretty important site, which comes with an admin console to help us manage the site.

Now I'm not very interested at just leaving the admin out in the open for anyone to "have a crack at" - how do large sites like ebay, facebook etc handle this kind of stuff? I'm sure they have some form of admin console for them to manage various things throughout the site, but I'm sure it's locked down in some fashion.

How does one protect an admin so only specific people can access it? I'm not talking about password protection (obviously it's already password protected), but I'm talking about actually protecting the login page so no-one else can actually have access to the page.

I think I read something awhile back about possibly using a SSL cert to only allow certain IP's? Little hard with that since most people have dynamic IP's. :(

Any ideas!?

I faced the same situation, you either only allow access to the console from certain IPs and then hardcode all public IPs or ranges that should have access to it. Or restrict access to a certain LAN range and only allow access from there. You can then set up a VPN solution and give all people that need access to the admin panel access to the VPN. People will first have to authenticate to the VPN and only then can they get access to the administrative panel (which has another log in). In this way people can still access the admin panel from anywhere (in case they are working from home) but it's not reachable for everyone.

I think it might also be a good idea to implement two factor authentication (but that's up to you to decide).

Also I suggest reading this question I posted a while ago on securing admin panels: Bruteforce vs Denial of Service


How Anomaly Analysis is differentiating from Heuristic analysis Taking a look at the discription of both kinds, orientation seems the same. while it isn't the same I can't figure the difference. In a Heuristic scan it looks for suspicious or malicious behaviors in a file, Anomaly analysis looks for anomalies in a file and its structure.

It's the difference between "weird" and "bad".

Anomaly analysis looks for the "weird". There is no judgement about whether it is "bad". In a lot of contexts, weird = bad, but not always.

Heuristic analysis learns what is "bad" and looks for that, even if it turns out to be "normal".


Reg HTTPS man in the middle Possible Duplicate:
  How is it possible that people observing an HTTPS connection being established wouldn’t know how to decrypt it?

A browser sends a request to gmail.com, gmail sends the cert with the pub key. if cert is intact and is verified from gmail, then client and server communicates. But whether a client C which knows gmail's public key can eavesdrop the data from gmail? Because the data from server is signed with the private key, Does anybody with the public key can eavesdrop it?

You can get more details from Thomas Pornin's link, but the short answer is that the client uses the public key to make a new key and encrypts it with the public key so that only gmail can decrypt it.  It sends this back and the two can start communicating.  Since the legitimate client expects communication to use the key that only it and gmail can know, the man in the middle can't break it without knowing Gmail's private key which is not disclosed.


http blocked over very low ports in Opera web browser Opera blocks the user from making http requests over very low ports (below 1024).  Why does Opera not allow the user to override this setting?

What is wrong with running a web server on, say, port 70 and why does Opera feel the need to prevent the user from doing this?

I am using opera 11.52 right now. For quick local web servers, I used MoWeS Portable. I set apache to listen on port 72, so in opera I typed

  http://localhost:72

and I am not having any such error.

However, when I changed the apache configuration to listen on port 70, I can replicate your error.

It's possible that because HTTPS is typically used for HTTP over SSL (HTTPS) that trying to run a url as a regular http://... gives an error. Though, in my testing I can run a non HTTPS server connection on 443.

Now, port 70 in particular is for the (virtually) deprecated gopher protocol which was more common before the rise of WWW http://en.wikipedia.org/wiki/Gopher_(protocol). So maybe they now block port 70 in particular.

As for your 443 error posted on the opera boards, perhaps as the first responder noted you were trying to connect to a port expected SSL and your server is not setup to automagically handle that for you. Did you get the same unsafe port error?

In your case it could be a combination of things, perhaps you can provide some more information to clarify.


can a malware conceal true browser history Suppose a zero-access malware like TDSS/Blue pill Kernel rootkit invades.
If it opens any of my logged-in sites (2FA enabled, so that they can't just go incognito or open in any other browsers or steal passwords) in my Chrome & my Google account is synced, would it be recorded? As well in Google Cloud history which I'd require the culprit to actually to go to my account cloud to delete, or low-level access can conceal or not record any remote access browsing history or any other malicious activity?

Would I see only my history/files if my PC is running virtually+TDSS, augmented "matrix" like?

Also, can login cookies be stolen & log-in from a different PC or would it stop working if used in VM or different browser version, hardware. GUID?

... both. on myactivity.google.com/myactivity, as well as local browser history.

Any process with the same or better permissions as the local browser can modify the same data as the browser does. Which means that any process you start as the normal user might modify the browser history. This can be done by directly accessing the files where the browser stores the history.

As for your activity log at google: a process which hijacks the browser or uses the credentials from the browser can do anything you can also do within the browser, i.e. delete activities by using the browser interface or add new activities (by browsing sites). But it has no direct access to the data stored at Google and can thus not modify the data outside of the intended way as would be possible with the local history. If that is needed the attacker need to attack Google 's servers where these data are stored and not your system.


Is this authentication scheme using JWT secure? I was wondering if you could review this authentication scheme for web application.

=== Login Page ===
Credentials Verification => Server issues JWT => Stored in a Cookie

JWT contains:
exp: timestamp
uid: UserID
HMAC-SHA512 Signature

Redis stores:
Key: UserID
Value: SecretKey (Only inserted if does not exist)

=== Authentication of Requests ===
JWT Decoded
$uid = UserID

Redis gets:
Value: SecretKey from
Key: $uid

JWT HMAC Verification using SecretKey
if verified
if exp not expired

ALL OK

So why using JWT at all when this is actually a stateful scheme and not stateless?

Verification performs only a single query to Redis, there is no need to do another to get the UserID
No need to store SessionID for every session, Redis stores only one record for unlimited sessions of given user.
No need to maintain expired sessions in Redis and delete them.
All tokens of a single user can be revoked anytime by changing SecretKey

Please tell me whether it is stupid or there are any security flaws so I do not implement crap.

In general looks good. However, few issues to think of

The userID isn't encrypted. If the request is not going over TLS, it's leaking that info to MITM. You might want to encrypt it.
Once user logs out, what prevents the JWT from still getting used, assuming it's not expired?


Strange POST requests to server's IP address. Is this security issue? Over past many months, I've been noticing these kinds of POST requests sent to the server's IP address (and not the domain):

POST: https://10.10.10.10 (example ip address)

Array(
    [VV27nX0RBekcnH5Xxq3k6nAi7DDWtKcmijZlBTzxTzyG2t/8jB_uqDIYzNz4BO9jgEoIvz1h/rsM7jtQGPMILbaX45ms4QAkzZLYr/B_SSw3QecgyUNL4HrrTYHmFAhz1lKL_p8j7hWfbXreQmdOG5dJxeOHFE8_0FFJH0ghnbvKUNz_vubkpTPpLmSZDWHiwIvH_Zf0z_aS0PNv9x5dT_i05N3hDUVyCxf_w6kO3fbwTiO5mzUR8T9mxSpx4VsqtqyHFlzpaO0vAOrrrg6hNVng5bn/GtfT836gLNtTypRdaKPt_5ulXmtMW3LhumBEhZVOkRs8l4ut2ilojiWA4yr1_UQsyJ_KkT1bURpgukfOcJ2CpxY_qoufFev49CfRDf1Yo2/EGtFFLQMEC5KiyYk3jK1dhTxYnYc2UA] => =
)

and

Array(
    [CFmxzCAeUO9tiRHIZW7HYsp4vEA7kKafBZA/1vjhZps11d3KcekSYp3zzr6WiK1T4hSJq7Mt2FK4eEvf1BZcsUZkPoj9zVo3vf9ipiYSEJRhQCkn/eO8IOc9l4u8Oezov2L6CGxtIypb4emUv1zDr72yKcOr1JHp6BIMMBW_2_LMe95r71QfMnc56ahycnEkl82NPqfGN69XJAM16GlyipzML9p3/_99YKC0/9ch58EQmfQ6EOFpRlTmcQpee_FPAOA0lyAVVMGhh0k5SL_W4t61O1Jk8MvFWsRsClhycA/rLgO5KFKijq2A1bk6Xa8Y04aAL87RTd7sz2QMDr1B/mewWLNDAcMmecv2kixQzWNUf0/0GSuANEP5JmhUzLSPIlzIRuZFAJNMTrGjp6U] =>
)

And all these are made from IPs like these:

IP: 83.35.164.71 (Andalusia, Albolote)
70.80.104.232 (Quebec, Montreal)
68.60.86.122 (Michigan, Battle Creek)

Generally these requests made at least a 100 times over an hour.

The server throws Symfony\Component\HttpKernel\Exception\MethodNotAllowedHttpException

Should I be worried about these requests? Are they trying to exploit any security vulnerability?

The short answer is no, this is not a security issue. That is said with the caveat that you are okay with the load these requests are putting on your server, and you are correct that every single one is being handled with the same error.

Things you should still do:

double check your stack to make sure that there are no known vulnerabilities that look like what's happening
hit your server with the requests that you're getting a make sure there's no information leaking out.
check that there might not be a timing attack happening.


Password Hashing Flaw Disclaimer: I know about the dangers of rolling your own auth, this example is intended to be used in a demo for various hashing methods.

I wrote this Node.js func to run server side to reinforce why we should not roll our own but use an existing lib (Bcrypt mainly) but I may be undoing my own argument as I cannot see how this can be easily broken.

The only way I can imagine is if the attacker can work out the fixed salt (pepper), perhaps by obtaining a known hashed pw, extracting the random salt (they would need to know the length) and constructing their own rainbow tables to try crack the fixed salt (this is very long and has high entropy).

function checkPw(pw, fullhash) {
    //random one time salt is first 12 chars
    var salt = fullhash.substr(0,12);

    //hashing the full pw, our random salt, the pw and a global fixed salt
    var hashpart = crypto.createHash('sha256').update(salt + pw + process.env.SALT).digest('hex');

    return (hashpart === fullhash.substr(12));
};

My questions is where is the flaw here? There must be something obvious I am missing?

There are several flaws:

First, I don't see why you would want to "reinforce the use of existing lib (Bcrypt mainly)".
Either you use a solid password hashing algorithm (BCrypt is good) or you don't. If you don't, you should not attempt to 'reinforce' it, but switch to a solid algorithm instead.

Second: Your code is, as you say, Javascript. Javascript implies client side hashing. Client side hashing is mood, there are several answers here on security.SE that explain why this is the case. (If you only choose to use Javascript for demo purposes, ignore this point.)

Third: Your 'fixed salt' is typically known as a 'pepper'. A pepper can add security in some very specific cases. A pepper works by being a secret. As a result, a pepper has no benefit whatsoever if used for client side hashing.

Fourth: SHA256 is a general purpose hash. It is designed to be fast. Fast is exactly what you do not want for password hashing.

Fifth: Your final comparison operator is vulnerable to timing attacks.

But is all comes down to the first point: pick a solid password hashing algorithm (BCrypt) and don't attempt to improve upon it.


Why OWASP Top 10 (web application) hasn't changed since 2013 but Mobile Top 10 is as recent as 2016? Latest edition of OWASP Top 10 for web application was in 2013 and for mobile applications, it is 2016. Why is it so?
Can we say that the pattern in the web application vulnerabilities is settled? Will same thing happen to mobile based applications?

The reason for the delay is that there has been little change in the Web T10. As stated by Dave Wichers, the Web T10 project lead, on 30 June 2015:

  Historically, we've produced a new OWASP Top 10 every 3 years because
  this seems to balance the tempo of change in the AppSec market, all
  the work everyone does to map their tool/process/other thing to each
  version of the OWASP Top 10, and the effort required to produce it.
  We've been producing a new one every three years since 2004 (i.e.,
  2007/2010/2013), and so a new version for 2016 is due. (Definitely not
  happening in 2015).

  However, we've been thinking about what might change in a 2016 release
  of the Top 10 and we don't actually think it would change much, if at
  all, which is kind of sad actually. I suspect some Top 10 items might
  move up or down based on the vulnerability prevalence statistics that
  we would need to gather and process, but I have my doubts that any new
  vulnerability types would break into the Top 10.

  As such, given that we don't expect the list to actually change in any
  substantial way, the project has decided to defer the next update to a
  2017 release.

This table from the 2013 T10 Release Notes demonstrates the small change:

The changes were largely due to rethinking how to categorize the raw data, not due to significant changes in the data.

Some have postulated that the level of effort for creating the T10 was a factor for delaying it. While it is a lot of work, I do not think that was a major factor. The Web T10 is OWASP's most recognized project and always has lots of volunteers (I contributed to the 2007, 2010, and 2013 ones).

Speculating as to whether the same thing will happen for mobile applications, I do not think that is likely in the near future. Mobile technology is still in its infancy and subject to rapid change.


Which is more secure? AMD DASH or Intel vPro In term of overall security is AMD DASH or Intel vPro preferable?

They both have:

Hardware virtualization
Remote Manageability
Hardware-enhanced security
etc...

I can't really distinguish the difference between these two technologies except that AMD is an open standard, what are the main differences and security issues of each of them?

DASH being open standard assures 2 things:

bugs can be found and fixed pretty fast, with the involvement of the community
there are no hidden backdoors

vPro has 2 problems:

is closed source and you cannot check for manufacturer back-doors
it was already hacked several times

So my vote goes to DASH hands down.


_ _ VIEWSTATE to Protect Against CSRF I am not a .NET developer and I am trying to understand how exactly does __ViewState protect against CSRF/XSRF attacks.

I came across the following :

security Stack exchange discussion on similar topic and
OWASP Guide to CSRF Protection

I am a little confused with how exactly is the CSRF protection happening here.
If we look at the below code taken from the OWASP link mentioned above:

    private const string AntiXsrfTokenKey = "__AntiXsrfToken";
    private const string AntiXsrfUserNameKey = "__AntiXsrfUserName";
    private string _antiXsrfTokenValue;
    protected void Page_Init(object sender, EventArgs e)
{
    // The code below helps to protect against XSRF attacks
    var requestCookie = Request.Cookies[AntiXsrfTokenKey];
    Guid requestCookieGuidValue;
    if (requestCookie != null && Guid.TryParse(requestCookie.Value, out requestCookieGuidValue))
    {
       // Use the Anti-XSRF token from the cookie
       _antiXsrfTokenValue = requestCookie.Value;
       Page.ViewStateUserKey = _antiXsrfTokenValue;
    }
    else
    {
       // Generate a new Anti-XSRF token and save to the cookie
       _antiXsrfTokenValue = Guid.NewGuid().ToString("N");
       Page.ViewStateUserKey = _antiXsrfTokenValue;
       var responseCookie = new HttpCookie(AntiXsrfTokenKey)
       {
          HttpOnly = true,
          Value = _antiXsrfTokenValue
       };
       if (FormsAuthentication.RequireSSL && Request.IsSecureConnection)
       {
          responseCookie.Secure = true;
       }
       Response.Cookies.Set(responseCookie);
    }
    Page.PreLoad += master_Page_PreLoad;
}

From what I can understand, the above code checks to see if there is a cookie named, '__AntiXsrfToken', already present.

If not, then a new random value is generated, which is assigned to ViewStateUserKey and also set as the value for the cookie, '__AntiXsrfToken'.

If the cookie is already present, the value of the cookie is simply taken and is assigned to ViewStateUserKey.

Now what I do not understand is that the whole point about an antiXSRF token is that it should not be guessable and certainly not be passed in cookies, because cookies will always be sent with every request by the browser.
In the above case, since the AntiXsrf token is being used in as cookies, how does it protect against it? And what really is the use of ViewStateUserKey and how does it play a role in the protection against XSRF here?

The issue is that the code sample in the OWASP guide is not complete.   Specifically, it is missing the implementation of the master_Page_PreLoad method that it wires up in the last line of the Page_Init method.

What you would see, if that method were included (and I may go add it shortly here) is that the ViewStateUserKey value being set by the cookie is being compared to the ViewState[AntiXsrfTokenKey] value that is being submitted with the form's ViewState field.

This is what provides the CSRF protection.  You are absolutely correct that when the malicious request is submitted, it will be submitted with your cookie, which will have your anti-forgery token, and this will be set to the ViewStateUserKey value.   However, what you're not seeing, is that this is being compared to the form value that was submitted.  In a cross-site request forgery scenario, that form value is going to be the attacker's anti-forgery token; the one that was added as the viewstate to be his ViewStateUserKey, and that's not going to match the match the value that's in your cookie.  So, validation will fail, and the request will not be successful.

Given nothing but the code on the OWASP page currently, you're right to be confused.


How can one execute code upon entry of folder in Windows? Theoretical question, I'm just interested in how could this be done. I remember I had a virus on Windows7/8 (can't quite remember which one tho) which made Windows BSOD upon entry of a folder which had a file that the AV recognised as a virus. It made Windows BSOD when entering the folder using Windows Explorer and using cd in command line.

To my knowledge, in Windows XP you could change the extension of a file to ".folder" and Windows hides the extension and shows it as a folder, but I read that the "feature" got removed by Microsoft, since it was considered as a bug some exploits later. Tho I don't think this is the case, since I had this happen to me in Windows7/8.

My WinApi experience isn't vast, but I was thinking that maybe using some hacky API calls one could monitor where the user is navigating in cmd/explorer. Tho again, don't think this is the case (why would Microsoft give a developer such powers?).

So, any ideas?

Yes this is possible. One way to do this would be to create a shared folder and share it with a mangled version of your own computers localhost. When cmd.exe tries to list the files in the folder, it will "look them up" over the mangled localhost and you should be able to intercept that network trafic. I don't think this would be possible without Administrator permissions however.


Is there a common name for a software defect that leads to unexpected transfer of secret over the wire? Suppose in a C++ program I use a memory region for temporarily storing an encryption key and don't overwrite that region afterwards. Then my program wants to send a data packet over the network.

Due to an error in code it reads not only the prepared data packet but also an adjacent memory region and the latter happens to be the same as the region which was previously used for the key. So although the program never planned to do so it does transfer the secret over the wire.

Is there a common name for such kind of software defects?

This bug is a buffer overflow -- the "reading" kind. A buffer overflow is where some code uses a buffer (a sequence of elements in memory) and accesses elements beyond the boundaries of the buffer (usually, it is called "overflow" when the access is past the last element, and "underflow" when it is before the first element).

Traditionally, the buffer overflows which lead to the biggest security holes are those where data is written past the buffer end, because it allows an attacker to alter the behavior of the attacked software, up to an including launching a shell. However, read accesses beyond the buffer end can be an important security issue, as your example shows: it can lead to leakage of confidential data (an encryption key is just the archetypal confidential data).

I have not encountered any specific term for the situation where the buffer overflows leaks confidential data which turns out to be an encryption key. Most pedagogical presentations of that issue use "credit card number" as a striking example of why data leaking is bad.


What is the state of Security in Comp Sci Programs In a previous question (How can I keep my programmer collegues informed about security issues?) there was a statement:

  "...and I realise that security topics are often barely known from both the student and the teacher."

It made me wonder what is getting taught.

So what is the state of Security-related teaching in a run of the mill CS program?  Are the basics taught?  Are more advanced topics taught? Perhaps elective?  None at all?

From the universities I have looked at, the basics are there (to a greater or lesser degree) but as it isn't a focus, there is very little effort put into updating the course material, for example some course material we have seen has code examples containing well known security vulnerabilities. This just isn't going to get rectified onthe low budgets universities have. And as far as advanced topics, you'll need to be on an Infosec related course.

Initiatives such as the Scotland & Northern Ireland Centre of Excellence in Security & Cybercrime are hoping to make a difference by using volunteers from industry to improve the training in order to lead to graduates who actually understand security.

(disclaimer - I am one of the volunteer supporters of the CoE in Scotland)

Edit - to be fair there are a couple of universities in the UK that have excellent security modules but these are normally part of infosec degrees (eg Royal Holloway, Westminster, Napier)


What to do with possibly infected files that need to be kept I have retrieved some old pictures/videos (mp4, many types of avi) of some old events that I want to keep, the problem is that these files have been sitting in confirmed infected machine for a very long time, and noone ever bothered to check what type of malware it was they just backed up and nuked it. My question now is what should be done with these files?

To clarify the files had been on both windows machines and linux server which have been confirmed to be rooted.
My desktop is running linux so if you suggest any software please make sure its compatible.

Media files should be relatively safe, because they usually don't contain any executable code.

There have been a few exploits in the past which caused specific media players/viewers to do unwanted stuff when opening an especially crafted file. But...

these exploits usually target very obscure formats which often aren't properly tested and
when you keep your software (including video and audio codecs) up to date, they are unlikely to be vulnerable to an exploit used by a malware several months ago.

So when you only copy media files with well-known formats, it is very unlikely to get infected.


What is required to verify that an x509 cert matches a key? Imagine that we have an x509 cert (if it matters, in .pem format) and a key supposed to certified with it.

How can I validate, that the cert certifies exactly that key?

My impression is that it is enough to examine that the cert and the key have the same pub key. I think it is because this is the only shared information between them. However, I am not sure.

Is it enough?

What happens if a possible attacker, having access to the cert, simply re-writes the pubkey part in it?

(Note, the validation of the cert is a different thing. Here I only want to be sure, that the cert certifies exactly that key.)

How can I validate, that the cert certifies exactly that key?

A certificate does not "certify" a key. What you describe is to check if the private key matches the public key in the certificate and thus can be used to prove ownership of the certificate against a third party. And yes, it is enough for this to check that the public key you have in the key pair is exactly the same as the public key of the certificate.

  What happens if a possible attacker, having access to the cert, simply re-writes the pubkey part in it?

In this case the issuers signature of the certificate will not match anymore and the validation of the certificate will fail.


Smartphone SSH clients with shared user I am writing an application for smartphones to provide very limited SSH usage. The user cannot perform arbitrary actions when logged in. They can run a specific script(s) only.

For various reasons it is not possible to implement passwordless login so the password must be provided from the smartphone for login. However I have to questions about the security flaws/problems with what I'm doing.

I don't want to give the users (in house employees) the SSH password directly, so they can't SSH from their homes and do what they like on the server. So my plan is for the user to enter their own password and use this as a key to store on the smartphone the (AES) encrypted SSH password. Only me or a server admin can enter this password on their phones, after downloading the application. This way they cannot login from unauthorized devices. Is this a good idea? I can't think of any security flwas in this.
I am thinking about giving all smartphone users one user account on the server, so they all log in to the same user by SSH. Is this a bad idea too?

Giving all users a shared account is not something I would consider. You would not be able to know for certain which user did what on the system, multiple people will be sharing the same account concurrently... All in all, it's bound to get messy at some point.

Imagine if one of them loses their phone, and you are forced to lock everyone out when you find out, not to mention that whoever finds the phone can log in and do harm and you would have a hard time figuring what was done by that user.

I would prefer the first option. Configure each app manually before giving access to employees, save and encrypt the key pair, or the password on the device and let them choose a password for unlocking application access. This way if a phone gets lost or stolen, you can simply de-authorize the affected key / account.


Is my Google session safe when my computer is logged out or locked? I've recently uploaded all the family photos to my Google Drive account. I have a strong password and 2 step verification enabled on my Google account. My home computer is (naturally) trusted and logged in to said account.

Would it be possible for someone to "access" my Google session in Chrome and thereby my photos when my home computer was logged out or locked? For example if it was stolen.

If your hard drive wasn't encrypted, someone could access your hard drive and view the cookies used for authentication, and bypass 2 factor.


How does one decide whether to block malicious scanning activities? On a typical day in the internet, there would be numerous botnets commanding zombie computers to scan for servers with vulnerabilities. Every now and then, a new exploit would be discovered. Then, the zombie computers would be reprogrammed to look for the new flaw. If a server is not updated immediately when an exploit for a particular software that the server is running is discovered, then it will be susceptible to an attack.

Monitoring and tracking malicious activities and actively blocking them takes time and effort and may consume more resources than just issuing a 403 or a 404 error. How does one decide if a certain scanning pattern is cause for concern to warrant taking pre-emptive measures such as totally blocking them?

Ideally you would like to manually inspect any abnormal occurrence. Since there are only 24 hours per day, this necessarily implies some heavy pruning, in which you automatically filter out the bulk of the automated scans. For instance, I see in my logs many attempts at accessing phpMyAdmin. I don't have this tool on my server, therefore I can safely ignore all attempts at exploiting its flaws. With similar rules for some other common attacks, I can lower the level of noise in my logs sufficiently so that I can afford to manually check the remainder.

Any attack attempt is cause of concern until you have fully understood and analysed the attack, and concluded that "it cannot work" (e.g. my case with phpMyAdmin), at which point you can ignore it. On the bright side, experience shows that between the discovery of a vulnerability, and its wide scale industrialization by bot nets, there usually is a delay of a few weeks, so patches will come first if you maintain your server properly.


DOM Based XSS and Adding HTML Elements So as a rule of thumb I once learned that adding or removing HTML with JavaScript/JQuery (.html(),.append(), etc) leaves yourself wide open for DOM Based XSS Attacks. It is now my understanding that this is not 100% true. Supposedly there is a correct and safe way to add/remove HTML with JavaScript. I am hoping to learn some on what this "correct way" may be.

So as an example lets say I have an input filed that allows a user to append an item to a list. In this case the input would also be added to an array to be sent in future requests. Additionally this list would have a button to remove said item from that list. In an insecure environment we might do something like the following (negating array):

var list = $("#my_list");

$("#add_btn").on("click", function(){
    let input = $("#input_field").val();
    list.append(
        '<li>'+input+' <button>Remove</button></li>'
    );
});

$("#my_list").on("click", "button", function(){
    $(this).closest("li").remove();
});

How might one do the same but without the threat of XSS?

Link to JSFiddle demonstrating different suggested solutions

Creating the DOM as string and using append or html indeed leads to DOM-based XSS. What you should do instead is to built the DOM elements using the proper functions and only inserting user-supplied input as text. Example:

<input type=text id=input_field value="">
<button id=add_btn></button>


XSS found in the United Airlines website An XSS bug was found in United Airlines by Strukt and Burelogic (full article here). Apparently they were using this to protect from XSS:

  Basically, the code overrides the native alert(), confirm(), prompt(), unescape(), and document.write()functions and nullifies them, so calling them does absolutely nothing. This was implemented as an "XSS protection".

I was wondering if using a base tag to point to a js file with a simple XSS payload would be blocked by the same function that blocked the XSS in the first place.

The CSP will block your JS from a third party website. However, in the event that you manage to find a CSP bypass, XSSObject.proxy will override those functions anyway, because a javascript src runs on the page it is called.


Is it worth the effort to store FTP passwords encrypted? I have a project to build a system that needs to push files to multiple third-party FTP servers. I have asked these third parties to provide a more secure interface; all have declined. So now I have this problem: I can implement some kind of reversible encryption, maybe in a separate process, all to secure passwords that will ultimately be sent over the wire in plain text. Why bother?

Do you think I could probably achieve better gains by focusing on the security of other areas of the application or is it worth the effort to encrypt this data anyway?

I wouldn't bother to be honest.  Most application store their database passwords in plain text,  i don't see this as being very different.  If you are on a shared host,  make sure only your user account has read access to the file.   I also strongly recommend using SFTP or FTPS,  if you aren't using one of these protocols then you are begging to be hacked.


Nmap stealth scan shows that port is filtered The title is really bad, but I was able to find better. I have installed Debian on VMware, and set iptables to block any traffic except port 80 (inbound and outbound). When I run a nmap scan it shows that this port is filtered. Should it be this why or not?

When nmap scans a TCP port (e.g. TCP/80 for HTTP traffic) a filtered response means that nmap did not get any response to the packet it sent.  The other options for TCP ports are "closed" which means that in response to the SYN packet nmap sent, the host sent a RST packet (essentially indicating that there is no service listening on that port) or "open" which means that nmap got an ACK packet back from the port (generally indicating that there is a service on that port which is happy to receive connections).

If you can connect to the webserver on port 80 on the machine in question from another system then that indicates that port 80 is open and receiving connections, so if you carry out an nmap scan from the same machine you browse from, you should have received an open response as the server is there and available for connection.


How do I safely inspect a potentially malicious website? Sometimes I'm interested in what's behind a malicious website. How do I stay on the safe side if I decide to inspect? I'm searching for methods that are quicker and more simple than running the website on a virtual machine.

Should I use cURL and view the HTML source in a file viewer? Should I simply view the source in the browser using view-source:http://malicious-website/?  Are those safe?

Why not just send the URL to Virustotal? Accessing a malicious website can be tricky. Using curl, wget, links -dump can be tricky depending on how the malicious content is served up. For example:

<IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteCond %{HTTP_USER_AGENT}
 RewriteCond %{HTTP_USER_AGENT} ^.*(winhttp|libwww\-perl|curl|wget).* [NC]
 RewriteRule ^(.*)$ - [F,L]
</IfModule>

Using mod_rewrite, I can feed you non-malicious pages. I can send you elsewhere, do whatever I'd like. Further, I can change payloads e.g.: instead of feeding you malicious, I can just change it to a non-malicious "Hello World" javascript. This may trick you into thinking my malicious website is harmless.

Normally when I have to visit a malicious website, I have a virtualized sandbox which runs burpsuite for interception, Squid proxy server, and a few other tools (noscript, ghostery, etc). What is the ultimate purpose of visiting outside of curiosity?


How many different passwords for a Linux System? How many different passwords should I use for my ArchLinux laptop that I'll be carrying around all the time ?

Here are the services I could need a password for :

Full disk encryption
User login
Root login
Password manager encryption
Backup encryption
BIOS Password
GRUB Password

Is it safe to reuse the same password, let's say for full disk encryption and backup encryption for instance, or for the user login and the password manager encryption ?
Or should I use 7 different strong passwords ?

Would it be safe storing the backup password/root password in a file under full disk encryption ?

I really do like @Serge Ballesta's answer, since my questionlike comment was meant to direct the OP that exact way. Although I will try to answer the question of:
"Where can I reuse a password without loosing too much safety?"
Let us look at the given list:

Full disk encryption
User login
Root login
Password manager encryption
Backup encryption
BIOS Password
GRUB Password

Since Full disk encryption and Backup encryption is basically the same thing (besides the fact there is another timestamp in it): I suggest it is safe enough to reuse the strong password for both of them. Typically you want your backup as new as it can without being broken/infected like your current system. Thus it is propably good enough for an attacker to obtain one of them.

Since you mentioned that your User login has administrative rights I guess it is O.K. if your Root login has the same Password or maybe an easy to remember variation of your User's Password.

(Since some of you want to kill me with fire now) I will focus on where I would definitly not reuse passwords.

Password manager encryption is IMO a save bet here. If you already have a password manager and you just have to remember one strong password, why would you reuse it?

I am less sure about BIOS Password and GRUB Password. I will not give any opinion on that, because I don't want to cause you trouble.

As others already mentioned: If you are able to store seven different and strong passwords in your brain for eternity: forget all my previous points.
DISCLAIMER: This is an opinion-based answer and I will not guarantee that reusing passwords this way is as safe as using different strong passwords.

PS: Please consider also the fact that sometimes wrench > password strength. (https://xkcd.com/538/)


Is it ok to write OidC Bearer token to log? During development we added to error logs details of http requests, including headers, to have better understanding for error investigation. Our architect pointed that we should not place sensitive information in logs. My question was should we consider bearer token as highly sensitive information taking into account  that access token is short-lived object.

The recommendations from  The OAuth 2.0 Authorization Framework: Bearer Token Usage  :

  If bearer tokens are passed in page URLs, attackers might be able to
  steal them from the history data, logs,  or other unsecured locations.

I assume that recording the tokens  into error logs is also not recommended.

However Asp.Net Core generates Information messages, that includes bearer token (both encoded and in JSON)

  2017-09-15 08:32:42.571 +00:00 [Information] Failed to validate the
  token
  "eyJ0eXAiOiJKV1QiLCJhb(I've
  truncated the token but full token can be decoded in JWT.io)".
  Microsoft.IdentityModel.Tokens.SecurityTokenSignatureKeyNotFoundException:
  IDX10501: Signature validation failed. Unable to match 'kid':
  'HHByKU-0DqAxxx',  token:
  '{"alg":"RS256","typ":"JWT","x5t":"HHByKU-0DqAxxx","kid":"HHByKU-0DqAxxx"}.{"aud":"https://webjet.group/eb694f3a-xxx","iss":"https://sts.windows.net/5de0e68cxxx","iat":1505464062,"nbf":1505464062,"exp":1505467962,"acr":"1","aio":"ASQAxxx","amr":["pwd"],"appid":"cc9aa533-xxx","appidacr":"1","e_exp":262800,"family_name":"Freidgeim","given_name":"Michael","groups":[xxx]","2d62738a-xxx"],"in_corp":"true","ipaddr":"121.1.1.1","name":"Michael
  Freidgeim","oid":"138f5eca-xxx","onprem_sid":"S-1-5-21-xxx","roles":["UATAdmin"],"scp":"user_impersonation","sub":"vTFBQRxxx","tid":"5de0e68c-xxx","unique_name":"Michael.Freidgeim@xxx","upn":"Michael.Freidgeim@xxx","ver":"1.0"}'.
  at
  System.IdentityModel.Tokens.Jwt.JwtSecurityTokenHandler.ValidateSignature(String
  token, TokenValidationParameters validationParameters)    at
  System.IdentityModel.Tokens.Jwt.JwtSecurityTokenHandler.ValidateToken(String
  token, TokenValidationParameters validationParameters, SecurityToken&
  validatedToken)
         at Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler.< HandleAuthenticateAsync>d__1.MoveNext()

Does it means that the risk is not so big, because Microsoft consider it acceptable to include  in logs?

Or should we exclude Microsoft/System Information LogLevel from logs? It will be quite restrictive, as we are using information logs for investigation, as well as for some monitoring/stats(such as number of logins).

What is the recommended approach regarding storing tokens into logs if we want  to satisfy both security and investigation requirements?

If part of the framework is logging INFO messages I would suppress those in a production environment. Chances are in the example given above it would also log a less verbose ERROR level entry?


Secure File Encryption/Decryption Capabilities As a preface to my question, let me state that I'm a relative newbie in the field of security.

I work for a back-office financial software provider that is responsible for processing, generating, and exchanging 1000's of files with 100's of 3rd parties each day. According to our most recent security audits, those files have to be encrypted whenever they aren't in use.

I can solve that problem pretty simply by using PGP encryption when we receive/build the file, and decrypting it when we need to read it/deliver it.

What I'm struggling with is how to do this in a secure fashion, given that the same environment needs to both encrypt and decrypt the files. I understand the paradox of what I'm trying to do...I'd like the same server to both encrypt and decrypt a file, but not allow a user that gets onto that server to do the same. I've contemplated the idea of having an administrator enter the decryption password upon the starting of the service, but that seems clunky.

Do I need a whole other route?

EDIT:

Here's the exact scenario that I'm wondering about...I realize it's counter-intuitive, but I'm hoping that the security community is brilliant enough to have solved this problem.

08:15 - Business Partner delivers a file of transactions for processing.
08:16 - File is decrypted using the keypair assigned to that business partner.
08:17 - As batch processing window has expired, file is encrypted until required later.
20:00 - Batch processing window is active, file is decrypted and transactions are processed.

We are wondering if there's a way to have an application handle all those (which we already have) and at the same time prevent Joe User from logging into the environment and decrypting the file at (e.g.) 14:03?

The reason it seems counter-intuitive to me is that if the application/server/environment has all the required information to both encrypt and decrypt, it would seem that any user that can get into the environment would also have access to that information. I'm hoping there's some fancy way of doing it that might avoid that case.

Make sense?

You are talking about security in layers, which is great.

The first issue is how to secure the data at rest and in transit, which you are doing with PGP. Your next issue is securing the system on which the data is stored.

It sounds like you are talking about the following issue: You are encrypting the information right before you transfer, but normally its sitting on the system unsecured.

The issue here is that while you are securing data in transit, its not secured on your system necessarily. To combat this, you make sure that your hard drive is encrypted and that you have good logical security and access controls - require strong/complex passwords, set appropriate file permissions, don't share passwords, don't share root or Administrator passwords, etc. You should not be allowing too many users onto the system, and furthermore should enforce role based access (e.g., only certain group or specific users can access where the file is stored).

You may also be concerned that since your private key is stored on the system, if the system is compromised then so is your private key. You can store the private key on a removable media to combat this or implement hardware encryption techniques.

If data is highly sensitive, it should only be decrypted when necessary and the private key should not be easily accessible.

Is there another issue you are concerned about that you can clarify?

Update
I guess the real issue is why does Joe user have system privileges that allow him to access the secure part of the file system? If you are using this server for this automated process, it sounds like very few people, if any should have access to this server. If they do, their group permissions should not allow them to access the secure files when encrypted or not encrypted.

You have to think about security in layers. First, let's do full disk encryption in case the disk is physically stolen at a point when the file is unencrypted at the logical level. Next, lets ensure the file is only decrypted when it needs to be. The decryption keys are stored someplace secure that only root or predetermined users can have access. The files when unencrypted can only be accessed by root and the batch processing user-account using file system level permissions. The only issue you have is if Joe User is also root or Administrator. To address this issue, you need to implement some expensive software or build a home brew solution for password checkin and check  out, also known as privileged identity management (PIM).

A PIM system is secured and stores shared secrets. It usually changes the passwords frequently on a time basis and everytime someone wants to log in or log out. For example, you want to log into a system: The PIM system uses scripts or other functionality to change the password on the remote system you want to access, then it gives you the password and prevents others from logging in while you have the password checked out. Once you are done or your session times out, the PIM system changes the password again so you can't get back in without making another log entry showing you checked out the password. These products are a bit pricey and might be overkill for your situation if you can properly restrict root access or limit root to physical console and use some physical security to prevent unauthorized access to the physical console.


How to prioritize npm dev vulnerabilities? Running SNYK scanning on my code base I find a number of HIGH vulnerabilities when I include the npm dev dependencies (e.g. running SNYK -dev test --file=package.json).

Examples of vulnerabilities:

https://app.snyk.io/vuln/SNYK-JS-SERIALIZEJAVASCRIPT-536840
https://app.snyk.io/vuln/SNYK-JS-NODESASS-540974

What are your take on fixing such issues in dev dependencies? Should they be fixed or simply ignored? And why - what are the good arguments?

How can I ensure that no traces (i.e. vulnerabilities) of the dev-marked code is found in the production code? Can I?

And what about insider threats?

How can I ensure that no traces (i.e. vulnerabilities) of the
  dev-marked code is found in the production code? Can I?

While deploying your code in production environment, you should install production only dependencies. This can be done as:

npm install --only=prod

It always best practice to use latest version of dev or production dependencies. There are several reasons for that:

If you are starting a new project you just want to make sure that you don't accumulate technical debt before even releasing your product.
Releasing an application with known vulnerabilities increases risk of compromising your application. An attacker could exploit a known bug in a dependency to further gain access to your application.
Also from compliance and regulatory perspective, you are obliged to provide a secure app to your customers. Having known vulnerabilities in your application means you have failed that obligation.
Well dev dependencies shouldn't be shipped with production code anyways, but it's always best practice to use secure versions in dev environment as well just in case to cover the case where someone accidentally pushes dev dependency in production.


Combining wildcard and subdomain-specific SSL certificates Not quite sure which Google terms to use to find the answer, so I thought I'd ask it here, presented as a scenario:

Say you have a corporate entity (Example Co) with a wildcard SSL cert issued for *.example.com. They contract with a SaaS provider and requests the SaaS provider use a custom domain: saas.example.com.

The SaaS provider creates their own private key (not shared with Example Co), generates a CSR and passes it on to Example Co., who then has it signed by their CA and returns it to the SaaS provider for use in production.

Later that year, the private key for Example Co's wildcard cert is compromised, but they don't know (so they don't revoke it). If the thieves man-in-the-middle connections to saas.example.com and present the wildcard cert, would the customer getting man-in-the-middled get any sort of SSL-related warning from their browser?

If the thieves man-in-the-middle connections to saas.example.com and present the wildcard cert, would the customer getting man-in-the-middled get any sort of SSL-related warning from their browser?

Usually not because the attacker presents a non-revoked certificate which is valid for the accessed host. The client would only reject the valid certificate if some kind of certificate pinning was used and the certificate did not match the expected public key.


Can a website see the file location of a document I upload? While applying to a job, I uploaded a resume to a recruiting website:

C:\myname\an\embarrassing\path\to\my\resume.pdf

Can the website see the file path of my uploaded document?

No!  Almost all modern browsers change the path to something like C:\fakepath\filename.ext in order to protect your privacy.


Does SGX provide a significant benefit for desktop operating systems? I have been looking into SGX (Intel's Software Guard Extension) for the last few days. It sounds like a very useful technology with some significant security advantages for many pieces of software. However, I have yet to identify a single piece of software that utilizes SGX on Windows 10. That's not to say there aren't any, but I use the same software on a CPU that supports SGX and one that doesn't, and none of the software seems to care either way. Windows 10 itself doesn't seem to be concerned with SGX support being present in the CPU.

Does SGX currently provide a meaningful benefit to desktop operating systems?

As a bonus, if you know of any pieces of software that utilize SGX on Windows 10 I'd like to know.

I know of at least 4 applications using SGX:

Software Ultra HD Blu Ray players are required to run decryption in an SGX enclave to prevent the DRM keys from compromise.

Windows 10 itself utilizes SGX in System Guard Runtime Attestation, which allows it to report to a third-party whether Windows has been tampered with. The SGX enclave prevents malware from tampering with the measurement process.

Intel Online Connect is an implementation of the FIDO U2F 2-factor standard that runs in an SGX enclave instead of a USB dongle.

Some match-on-host fingerprint readers use SGX to prevent compromise of fingerprint data by malware on the system.