Google safe browsing vs traditional anti-malware scanners

"Google Safe Browsing" is mostly a large directory of Web sites which appear to contain malware. When you use Safe Browsing, your client is talking to the Google's dedicated server, with a question like this:

  — Tell me, mighty Google; I am about to visit evilhackerzfrompatagonia.com. Is that safe ?

To which Google will respond either:

  — Do not fear, friend browser. I went to that site myself yesterday, and nothing on it appeared amiss at that time.

Or:

  — Stay your network packets ! That site is a malware-infested hellish server; or at least so it was when I last had a look. Steer away from it !

So that service is really relative to what Google's systems so when they last visited the same site. However, a site owner may detect whether a given visitor is an actual human, or Google's automated services; therefore, an evil site owner may elect to show a collection of pictures of cute kitten to Google, while sending malware to everybody else. Google Safe Browsing would be none the wiser.

Other anti-malware tool inspect what you actually download. They don't prevent the fateful connection, but they see exactly what is entering your computer, and they sit sufficiently early in the input data flow that they may prevent incoming malware from harming your computer, if they detect it as such.

Such tools are in a better position to make an accurate diagnostic of the malwareness of incoming data, since they work, by definition, on that exact incoming data, and not on what was sent to another system the day before. In that sense, they seem "more secure". On the other hand, all the detection must be performed by your computer, which may not necessarily have a lot of available computing power for the job. More importantly, Google's systems have a worldwide view and thus a lot of data to cross-correlate with.

So the answer is mixed: though Google Safe Browsing is easier to fool by sending it innocent harmless files, it is also much better at deciding whether a given file is malware or not. So the two kind of services are really complementary. You don't have to choose between Google Safe Browsing, and a local anti-malware tool; just use both !


WebRTC uses ICE to generate a list of IP address that can be used to reach your computer. This is important when trying to establish a direct connection. However, this list can sometimes include IP addresses that the user would rather not disclose. As explained here, this behavior is counterintuitive when using a VPN as their actual IP address can be discovered with WebRTC:

Many such users assume that using a VPN will obscure all their browsing and their real external IP address, which could be used to locate them.
However many VPN configurations don’t properly disable local interfaces, and so users of those VPNs might be surprised to learn that their real external IP addresses are exposed by ICE.

So, if your browser is giving out your real IP address, it becomes possible to create direct connections to that interface, bypassing the VPN.


While it is possible that it is a technique to fool the browser I would seriously doubt it.

The vast majority of products I've dealt with that provide deep inspection only provide a single root certificate from under which all of the SSL inspection is executed. While it isn't definitive my leaning would be to say that anything that isn't using the known inspection root is being passed without inspection.

I personally don't find it all that unusual to get a big mix of sites that have deep inspection disabled. It seems that 3/4 of the helpdesk tickets that get escalated to me have to do with disabling HTTPS inspection.


SQLi Filter Bypass with banned table/column names

You can do things to reference the table or column name from the schema instead of supplying the actual name.


Asymmetric cryptography tries to provide some advanced features, namely the asymmetry, the property which allows the public key to be made public, without revealing the private key. This takes structure. We need mathematics. A key for signatures or asymmetric encryption cannot just be a bunch of bits; it must be a mathematical object with very special characteristics.

That mathematical structure can be leveraged for attacks, which forces us to use a lot bigger values. For instance, with RSA, the public key contains a big integer (the "modulus"): this is a composite integer, but factoring it into its prime factors allows for breaking the algorithm. We know some rather efficient factoring algorithm; the General Number Field Sieve will thus defeat a 1024-bit RSA key (a key whose modulus is an integer between 21023 and 21024) with an estimated cost around 277. If we want to achieve the same level of robustness with a symmetric key (which is just a sequence of bits, nothing made public) then we just need 78 bits.

The generic attack known as "luck", in which you try all possible bit sequences until the right one is found, has average cost 2n-1 for a n-bit key. For symmetric cryptography (with a good algorithm), we know no better attack, and any key of 100 bits or more will be safe for decades. With asymmetric cryptography, we have the public key and its structure to work with, allowing for much more efficient (but heavier in mathematics) attacks, which forces us to use much bigger objects (larger keys).


Does a log entry with "SPT=81" despite nothing listening on that port indicate my server is hacked?

... SRC=my.server.public.ip DST=109.89.132.126 ...
... PROTO=TCP SPT=81 DPT=587 ... RST ...

This is a RST. It will be generated by your server if a remote system (in this case 109.89.132.126) tries to connect to a port on your system where no one is listening. Given that no one is listening on port 81 on your system it is sufficient that 109.89.132.126 has send a packet with source port 587 to your system port 81.
In other words: there is no need to hack your system in order to cause this log message.


How does one steal files by connecting to a laptop's WIFI / Bluetooth?

If they have physical access the laptop's wireless devices can be hacked, while it does not display as connected, it is connecting to a Wifi hotspot of theirs to send your files.
the laptop is on or in a suspended state and they are within Wifi range they can exploit vulnerabilities in the laptop's drivers and hardware and send the files.
WakeonWLAN could be exploited and the files sent when the laptop is running again.


How do I securely embed an  tag using a user-given URL?

Avoiding attacks on your site

You need to validate that the string you received is valid. Remember this principle: you must white-list acceptable strings rather than black-list unacceptable ones.

Ensure that the string is a syntactically-correct and escaped URL. Escaping the whole URL avoids it containing " or > which could break your site's syntax.
Ensure the URL is absolute, to help avoid directory traversal attacks. You'll also need to figure out how your web server handles symlinks accessible from within your /var/www folder, and how your server resolves absolute URLs with references to parent directories e.g. www.server.com/../../../etc/passwd.
Ensure the URL uses a known, supported protocol of which you understand the implications: http or https. ¹

Protecting users' privacy

There's a priori no point in checking what the file being pointed to actually is since it can be changed any time by the user who provided the link without you knowing. If that code triggers a bug in the browser's rendering routine, then the (sandboxed) browser process that renders your site will be compromised.

You should be aware that images can be used to collect the IP addresses of your own users. Attackers just need to wait and collect which IP addresses query the image they used for your site.

The 401 attack should be fixed by now, but some browsers might still not handle it properly. It's been discussed on this StackExchange thread. As per this Chrome bug tracker thread, Chrome no longer displays an auth prompt when an image triggers a 401 error.

There's a common solution to these two threats: download and cache the image. If you can afford to do that, you'll have a higher certainty of users being safe. I know that's not what you're asking for but it's your best course of action.

Avoiding attacks on your server!

Since you're now caching the image, you need to white-list it once again.

Make sure the image corresponds to one of your supported file formats (e.g. PNG/SVG/JPG/GIF)
Make sure the image is syntactically correct
Reconstitute the images by extracting whatever information is relevant to displaying them and by dumping whatever information you don't recognise or need -- for instance SVG files can allegedly embed JavaScript, which you might not want as it would be executed within your domain by the browser. ²
Impose reasonable limits on the resolution and file size of the image

¹ It's been pointed out that an attacker could do something such as file:///some/user/secret/on/their/local/machine. If you did not retrieve the file but just left the URL as is, this could cause the file to be loaded by the rendering process that renders your site. In conjunction with a second URL to an image that successfully exploits a bug in the render, an attacker could retrieve the content of this file.

² Note that SVG files are particularly dangerous, and that there are no available tools to filter them currently.


CRTM is saved in the Platform Configuration Registers (PCR), register 0 to be more precise (PCR-0). CRTM is (physically) embedded into chip silicon and provided by the BIOS, but is a logical part of the TBB (Trusted Building Block). The measurement itself is stored in PCR0.

In order to fully understand how CRTM works, you should study the chain of trust in more detail.

The (static) chain of trust starts at powers on (or reboot), which resets all PCRs to their default value. The first measurement is made by hardware (the processor) to measure a digitally signed module (called ACM - Auth'ed Code Module) which is provided directly by the chipset manufacturer. The processor validates the signature and integrity of the signed module and if it is valid it starts executing it. The ACM then measures the first BIOS code module, which can make various additional measurements.
The measurements of the ACM and BIOS code modules are extended to PCR0, which holds the (CRTM), as well as the measurement of the BIOS TCB (Trusted Comp. Base). Then the BIOS measures additional components into PCRs, from PCR-0 to PCR-7.

Physically, the PCR is stored in the TPM (Trusted Platform Module) is a microcontroller security chip that resides on the mother board of most enterprise level computers that are shipping today.


SSH - request public key instead of fingerprint?

You can use ssh-keyscan to get the information you want.  It's primarily designed for gathering public keys over an initial trusted network connection and automatically adding them into the known_hosts file.


Differences between Cookie vs Session Variable to sensitive data

1) how safe is to store an "User" object, with many properties (including encrypted pass) in a base64 string?

You should never store the password anywhere. It does not matter if it is encrypted or not. You should not even store an encrypted copy on the server side. You should use something like bcrypt to create a secure hash of the password that you use for validation.

  2) how safe is to store sensitive plain text data?

A better question would be "how unsafe is it to store sensitive plain text data?" The answer is that it is very unsafe. Of greater concern than the encryption portion is that the question makes me think that you are planning on trusting spoofable data that comes from the client. You must never do this.

If you are to store information used for authentication on the client, it must be done in a secure manner. You sign (eg: with an HMAC) to make sure it isn't tampered with. You encrypt data to keep it secure. And you never store anything but a password hash (eg: with bcrypt) as they are so sensitive that even encryption isn't sufficient for them.

Finally, I strongly recommend that you don't actually use a custom authentication system for anything but playing around. Even the most experienced security developers' authentication systems take lots of help and testing and real life usage before they can be considered secure.


Securing a Ubuntu system on Amazon Web Services

Have a read of the answers on the Hardening Linux Server question for guidance on the server part.

Using EC2 shouldn't change your basic security concepts - but be aware of the implications of using a cloud service, especially in the following areas:

availability - for a single instance, you could find you have less control over availability
security of hypervisor - you have little control over their end so need to trust Amazon, but make sure your login to Amazon is protected at your end

SSH definitely is a good idea - and using certificates is recommended over solely using username and password.

As regards securing java - that could depend on a wide variety of factors. Possibly worth asking a separate question.


Is there a hash algorithm that can identify similar files or strings?

"Approximate matching algorithms" (still a NIST draft) or "similarity preserving hash functions" could be of your interest.  These algorithms are specifically designed to determine similarity between two digital objects. Some of the proposed algorithms till now (and useful) are (chronologically): ssdeep, sdhash, mrsh-v2.

To determine the similarity between objects these algorithms require a minimum chunk of data. Mrsh-v2 performing best in terms of minimum size required.

Mrsh-v2 seems to be really promising in terms of performance and minimum chunk size required, but still under development. I hope it potentially solves your issue of handling similar files.


How can I avoid my password being harvested by key loggers from internet cafes?

if you do not trust the medium: do not enter sensitive information. typing in your password in some obscure way is just that: security through obscurity, which never works.

other than that: you might be able to achieve some level of security in such open places if the password you entered changes for the next login, see one-time-passwords. (note: '2-factor-authentification is a hybrid scheme where you know already one half of the password (which keeps constant / static) and then you get the other half by sms or any other means; that 2nd half is a one-time-password)


Is it a good idea to host a SFTP server within a dockerized environment with mounted host directories?

It's important to note, when considering container security, that standard Linux containers are literally just Linux processes with some isolation techniques applied to them.
There are security considerations relating to them, but they're really similar to what you would have for any other process running on a host.
In this case, when you mount files inside a container, you're giving the contained process rights to operate on them, in the same way as you would if you gave an SFTP daemon running on the host access.
Key security concerns are likely to be :-

Ensuring the container image comes from a trusted source (e.g. you control the image building process)
Ensuring that the image is patched. Generally container images come with Linux base files to support the running daemon, so ensuring patching is maintained is important.
Hardening the container image. Important issues include making sure your container isn't running as the root user (many images default to this) and only installing packages that are neded for the operation of the daemon
Controlling what files can be mounted from the host. The Docker daemon runs as root, so if you let a user define what directories they can mount, it's possible fo them to mount sensitive directories inside the container.


You can issue shielded containers for the cards. These are plastic sleeves that feature a thin sheet of metal on either side of the sleeve, making it impossible to scan the card. When the user needs to authenticate or verify, they can simply take the card out. There are more luxurious shielded containers that separate the plate from the card when pinched together, making the process easier and quicker.

Of course, this does not offer any protection to users willfully allowing their card to be duplicated.

The problem with your suggested solution is that when a counterfeit card is used before the legitimate one, the counterfeit will maintain functionality while the legitimate card will be marked counterfeit. At best this will serve as an indicator the card being offered is either copied or a copy.

I'm afraid that is as much as you can do to protect a static token.


No where to run, no where to hide - suggestions to improve personal security needed

A workable method is to use a virtual machine. Run a VM with a Linux in it, and do your browsing from that VM. VirtualBox "seamless windows" may help making the integration with your Windows system easier.

Of course:

This may protect your Windows system from whatever occurs in the Linux side of things, but remember that at least part of your sensitive data is in the browser itself -- e.g. authentication cookies for various sites.
If you, as a user, want to download a Windows application from a site, and then run it on your Windows machine, and the application turns out to be hostile, then no amount of Linux or VM will save you. Just don't do that.

(This is an indirect advantage of the Linux ecosystem: on Linux, virtually every application you will run on your machine comes as an "official" package, with secured distribution. On Windows, you install software from many sources, and you have to verify yourself whether the source is trustworthy or not -- which is a lot of work and nigh impossible for the non-technically inclined end user.)

Most of security comes from not doing anything insecure, especially what advertisements ask you to do in a very insistant way. If you cannot resist ads, then don't browse the Web.


Should VPN passwords be stored in plaintext?

Yes, they need your plaintext password to make the VPN work, simply because their service is badly configured. They shouldn't need your password in plaintext.

The problem is that they use your plaintext password in their authentication procedure. When a new user creates an account, the VPN provider should properly hash their password and use that hash to authenticate them. From what I see, their service is badly configured.

Note that, when you changed the password the first time and they sent you your new password in plaintext, it doesn't mean that they stored your password in that format. They could have sent you that email before hashing it and storing it in their database. (Although sending any credential by email is a bad idea.) However, getting your password in plaintext when using the lost password feature proves it.


How to prevent users from downloading information from our search engine?

If the user invokes over x amount of queries per x amount of time which seems impossible via a human then you'll want to generate a captcha to prevent bots.

If the user invokes a silly amount of requests just ban his/her IP for x amount of time as it's clear they are using some form of botting.

You could generate a key everytime the user searches (This will prevent basics bots but is by-passable by complexed bots as they will read the key and throw into parameters). If they are missing the key then display an error.

So, let's pretend you have Default.aspx and Search.aspx would set the key set in form data as hidden field. So, default will direct you to Search.aspx with a key. If you go directly to Search.aspx you won't have key so you can't search. Once you hit "Search" button it will pass it to server and you'll just validate that key.
So have hidden field such as:

<input id="hifKey" type="hidden" runat="server" value="{getfromserver}" />

This key would be only validate for one search, after validated and used generate a new key.

This would prevent basics bots but do bare in mind it's still bypassable as all you need to do is create a .NET application and use HttpWebRequest and read out the HttpWebResponse data to Default.aspx then to get a key then do search on Search.aspx and keep reading next key from <input id="hifKey" type="hidden" runat="server" value="{getfromserver}" />


Potential damage of someone getting your online banking password

It will depend on your bank, obviously, as some will require other authentication for actually transferring funds (several use 2FA, seperate data, text message authorisation), but risks I can think of include:

Transferring funds, for banks that would allow that
Paying bills, then socially engineering refunds elsewhere
Collection of information for identity fraud or social engineering attacks ("Hello Mr Blank, I see that your account ending 1234 is overdrawn due a payment to [Actual Direct Debit Here], did you make this transaction, I'll just need to run you through security questions at this point

Don't underestimate the power of the information that your banking password allows access to.  Your personal details can be used against you, or to persuade others that an attacker is you.  Once someone has the same access as you, all bets are off, and your bank account is empty.


Revoke access from intranet if an employee leaves the organization

I think that if you continue down that line of thinking towards a rock-solid solution, you're going to have to consider things like "what if the weekly email is spoofed?" ... "Maybe I need to digitally sign those lists", etc and you are going to end up inventing something very similar to a Certificate Authority.

Use an in-house Certificate Authority

I think the simplest (and cheapest) way to accomplish your goal is to use a VPN with client certificates to grant employees access to the intranet. To issue and manage the certificates, set up a hierarchy of Certificate Authorities (for example with openssl): the root would be operated by the parent company and each local branch office would run an Issuing CA to actually issue and manage the certificates of employees at that office.

Configure the VPN to use client-certificates

Set up the firewalls for the intranet servers to only accept connections from inside the network, requiring users to VPN in. Configure the VPN server to require client certificates that trace back to the root CA operated by the parent company. Because of how certificates work, every time a user tries to log in, the VPN server will check with their Issuing CA to make sure their certificate is still valid - so each office manages their own database of employees. This means that local administrators at each office can add (aka "issue") or remove (aka "revoke") employees at their leisure and the VPN will automatically accept / reject their logins. I believe that most commercial and open-source VPNs support the client-cert mode of operation.

Another option: buy a COTS authentication product

A slightly more complex (and expensive) option is to purchase a certificate-based authentication web application that acts as a gatekeeper to your intranet and requires users to provide their certificate and a proof-of-possession of private key. I won't mention any specific products because my company sells one and I don't want to be accused of conflict of interest.


How dangerous is the remote Jeep Cherokee attack?

Here is the copy of the paper they wrote on this topic, linked directly to the section on "Cellular Exploitation":

http://www.ioactive.com/pdfs/IOActive_Remote_Car_Hacking.pdf#page=42&zoom=auto,61,288

As you can see, it was not necessarily trivial to discover the method. However, now that it has been done, you can see that this was the way to find vulnerable cars:

  To find vulnerable vehicles you just need to scan on port 6667 from a Sprint device on the
  IP addresses 21.0.0.0/8 and 25.0.0.0/8.
  Anything that responds is a vulnerable Uconnect
  system (or an IRC server).
  To know for sure, you can try to telnet to the device and look
  for the ERROR “Unknown command” string.

Now, linking the IP to a "car I see on the street" is a much more difficult task. The authors write this:

  If you knew the VIN or GPS, you could scan the IP ranges where
  vehicles are known to reside until you found one with corresponding VIN or GPS.
  Due to
  the
  slow speed of devices on the Sprint network, to make this practical, you’d probably
  need many devices to parallelize the scan, possibly up to a few hundred.

Earlier in the paper, they detail methods of accessing information like the VIN or GPS coordinates.

Of course, you can't do this particular technique anymore, because changes have been made. The vehicles have (nominally) been patched, and more importantly, the sprint network no longer allows it.

The authors used a hacked femtocell in their research, and I suspect that method is still a viable way to do this.


This looks like automated attacks to test for different injection vulnerabilities. As far as I can tell, there is no actual mallicious payload here. The attacks are instead design to detect if the site is vulnerable. I asume that sites will be attacked with real payloads if the tests are positive.

The first three are XSS attacks. The first two will try to pop up a prompt with the number 14721850.00337 in it. If you multiply that number by 100 you get a Unix timestamp that was three days ago. I guess it is used for timing the attack somehow.

Some common tricks to fool filters are employed - mIxeD CAsE, prompt instead of alert, / instead of space.

The forth and the fifth tests for SQL injection. It tries to make the database server "sleep" for a while. That makes it easy to check if the attack was successful. If it takes a couple of seconds to get a reply, it worked. I think the forth one is aimed at MySQL and the fifth at MSSQL, but they might work on other systems as well.

So do you need to be worried? Not really. This kind of automated attacks are common against any internet facing servers. It does not need to mean that someone is actively attacking you specifically, or that you are vulnerable. But still, it is probably a good idea to test if the attacks work or not, because if they did you can be sure that they have been exploited by now.


Is VeraCrypt encryption of VHDX correct?

To validate your trust in an encryption process, just place a canary among your clear data. A good canary is any file with a basic pattern easy to find out with any search tool (I used a file filed with 1MB of U == 0x01010101).

Boot from another OS, for example an USB key with any Linux version. Mount your encrypted disk, and search your canary.

Your canary will detect the leak and save you (your data): Canary use in coal mine.


Exploits or other security risks with SVG upload?

Could an SVG be constructed in such way, that when reading meta data it makes the server unresponsive. and could be used as DoS attack on the server?

What do you mean by metadata? If you are after width and height, you would have to parse the SVG files at least partially to get it; there's no shortcut of reading a few bytes from the header like there is with many bitmap formats. That brings in the usual risks of XML parsing, such as:

external entity/DTD-subset inclusion attacks against remote files, local-network sensitive resources, local-machine sensitive files and device-files
nested entity expansion bombs
pathologically-nested tag structures might hit recursion resource limits

as a standard precaution you would disable all DTD processing, XInclude, XSL, XSI and entity resolution.

  Could an SVG be constructed in such way, that when rendering the SVG on the client, the client becomes unresponsive and potentially makes every users browser on my site crash?

Possibly, but it's just as possible that could happen with a bitmap format. See eg the corrupt PNG file vulnerabilities of a while back.

More of a concern for SVG files is that they can include JavaScript, which will operate in the security context of the hosting site, so you have cross-site-scripting to worry about.

Actually all types of uploaded file are vulnerable to this, albeit not in such a direct, easy-to-exploit way. In some cases browsers (particularly IE) will content-sniff them, and if they see things that look like tags they may potentially reinterpret them as HTML, including JavaScript. Also there are some side-issues with treating uploaded files as Java applets and Flash policy files.

The standard mitigation for all of these problems is to serve your untrusted resources, whether bitmap, SVG or anything else, from a different domain to your main site: a domain that has no sensitive session (cookie/auth) information in it and no ability to script into your main site's domain.

  Also, would it be good practice to generate a small (200x200px) PNG for a thumbnail, or is it better to just manipulate the SVG itself with a zoom factor or something?

That would be a nice touch, but you'd have to drag in some dependencies to render to bitmap, for example Batik if you are using Java. Naturally bringing in a new complex library increases attack surface; it might be a good idea to run the thumbnailer as a separate low-privilege-account low-priority daemon task.


Is it worth it to implement both SHA2 and SHA3 at the same time?

You are doing it wrong, and thinking it wrong. The problem with password hashing is not, and never has been, about collisions. The main problems with password hashing are speed (hash functions are too fast) and parallelism (a hash function is always the same as itself).

There is a lot of theory on password hashing. As an introduction, read this answer. The simple one-line summary is: use bcrypt.

Making anything better (i.e. more secure) than bcrypt is hard (some people are trying, and do it the right way: with an open competition, public research, and years of effort). However, making something which is much worse than bcrypt is very easy, and a lot of people achieve just that seemingly effortlessly. By your scheme with a combination of SHA-2 and SHA-3, you would be on the right track to add one more person on the depressingly long list of people who felt that creativity was a good thing in cryptography, and paid dearly for it.

(None of this says anything about SHA-2 or SHA-3 as generic hash functions. But, despite the names, hashing and password hashing are in fact very distinct activities, do not have the same requirements, and should not use the same algorithms.)


Bluetooth vulnerabilities for Internet of Things demo

We ended up creating a thermostat out of 2 Arduino Uno's. One used to receive and send data through bluetooth and the other one purely for encryption and decryption of the data, they both were connected through I2C.

We demonstrated data being sent and received with and without cryptography. And sniffed it by using the Ubertooth One. Only problem we stumbled upon was that Bluetooth itself used its own encryption to encrypt the packets. So it was actually hard to show it, but we got the message across.

Using HCISnoop or something likely on Android we could show the packets being sent and received. But of course this was a bit of a cheat because the point was to demonstrate someone, a third party, sniffing your data / codes etc.

Edit

In theory the encrypted packets with Bluetooth encryption could easily be decrypted using crackle, I believe.


hundreds of users creating mail.ru and projectgold.ru accounts on my application db

Here are the Vbulletin recommendations:

(Before reading the quotation below, try to enable reCaptcha V2 as @Mirsad said.)

  Most people are being hit with a lot of spam these days. Some things
  you can do to reduce this are:

  Moderate new registrations Admin CP -> Setting -> Options -> User Registration Options -> Moderate New Members -> Yes
  Activate email verification Admin CP -> Settings -> Options -> User Registration Options -> Verify Email address in Registration
  Upgrade to at least vBulletin version 3.7 or higher. These versions have several Human Verification Options. Admin CP -> Settings -> Human
  Verification Manager ->

  Image Verification:  This is the same Images Verification Captcha as
  in older versions of vB, except that this now requires both GD and
  Freetype 2 to be installed in PHP.

  Question and Answer Verification This allows you to set up a Question
  and Answer verification during registration. If done correctly it will
  be almost impossible for bots to enter the correct answer.

  reCAPTCHA™ Verification This uses the reCaptcha service. You will need
  to register with them and get both a Public and Private key.

  * Note: As per this announcement, we recommend using the Q&A method with multiple questions. * After you have chosen the method you want
  to use and have set this up, then make sure the correct Human
  Verification options are set here: Admin CP -> Settings -> Human
  Verification Options

  And if you have chosen the Image Verification option then you need to
  choose either GD or ImageMagick here: Admin CP -> Settings -> Options
  -> Image Settings You can go back to the Human Verification Manager to make sure the image is showing correctly.

  Note: Both are equivalent. These are also required if you use
  thumbnails for attachments or wish to automatically resize pictures
  that are too large.

  Ban 'free' email domains many spammers use. Admin CP -> Settings -> Options -> User Banning Options -> Banned Email Addresses

  See this thread for a list of commonly banned email addresses:
  http://www.vbulletin.com/forum/showthread.php?t=148061

  Set these options for the Unregistered, Users Awaiting and COPPA usergroups: Admin CP -> Usergroups -> Usergroup Manager -> Edit ->
  Can Use Email to Friend -> No Can Email Members -> No

  Require Human Verification on Configured Actions -> Yes

  Add a new required question to registration. Although there is a Q&A option in the Human Verification Manager, at this time these is no
  way to use this in conjunction with Image Verification or reCaptcha.
  However there is a workaround for this. You can create a required
  profile field to add Q&A to the registration process. To do so, follow
  these instructions: Add an extra question to the registration to
  prevent bot registrations.
  Restrict Email to Friend to Registered Users. Some people have reported that spammers are using the 'Send Email to Friend' function
  to spam others from your forums. To reduce this make sure that your
  Unregistered, COPPA and User's Awaiting groups have the 'Can Use Email
  to Friend' option set to 'No'.
  Stop bots spamming through the Contact Us link. Admin CP -> Settings -> Options -> Human Verification Options -> Check 'Contact
  Us' and 'Register'
  Enabling Spam Management. vBulletin supports managing spam through the Akismet and Typepad Anti-spam services. Both services require an
  API key to use. Here is how to obtain those keys.

  Akismet - To obtain an Akismet key, you need to sign up for a
  Wordpress.com account. This will give you a key to use within
  vBulletin. After signing up please see this page for instructions on
  retrieving your key: http://faq.wordpress.com/2005/10/19/api-key/

  Typepad - Typepad also requires a key to be used. To get one go to
  this link here: http://antispam.typepad.com/info/get-api-key.html

  Once you have your key, you need to enter it into your vBulletin
  Options under: Admin CP -> Settings -> Options -> vBulletin Options ->
  Spam Management -> vBulletin Anti-Spam Key Powered by Akismet

  Note: Either key goes into the same spot. On the same page set
  'Anti-Spam Service' to the appropriate service. You can only use one
  service at a time.

  Note: Because of recent spam attacks, we strongly recommend that you
  combine one of the Image Verification options along with a Q&A as
  described in item #6 above.

  In addition banning free email accounts (#4) will be a major help as
  well.

source


Should I be able to see patterns in a HS256 encoded JWT?

tl/dr: Your selected version of the JWT doesn't encrypt anything, it merely encodes it for easy
  transport.  The data in the payload is not meant to be a secret.

You have a JWS (JWT with signature).  What you are looking at is simply the base64 encoded data payload.  A JWS contains 3 parts:

The base64 encoded header
The base64 encoded data
A cryptographic signature

Base64 is simply an encoding format - not any kind of encryption, and is not meant to hide the data.  Rather, it just makes sure it is composed solely of standard ASCII characters that easily survive transfer between different systems.  As a result, if you were to take everything in between the two periods and run it through a base64 decoder, you would see your original payload data without issue.

The key therefore is simple: a JWS isn't meant to hide the data.  It is simply intended (through the signature) to ensure data integrity, i.e. if someone changes the data payload then you will know because your signature will no longer match.

Alternately you could use a JWE (JWT with encryption) to hide your data.  See Bob's excellent answer for a more detailed comparison between JWT, JWS, and JWE, all of which are closely related.


What security risk does it mean if you have your db password and security token publicity available?

It is an information disclosure that weakens the overall security of the website. By itself, I would rate this vulnerability as medium risk but an overall analysis is required in order to determine how this affects the overall security.

The database password could be reused in a different location, it can hint on how other passwords are built and what character sets are used. Maybe the database is accessible in case the website shares hosting with other websites. The table_prefix parameter can prevent exploitation in case there is a vulnerability in the website that allows SQL injection. With the information in table_prefix public, such protection is no longer provided.

It is also visible that the WordPress security keys are not initialized. WordPress Security Keys are a set of random variables that improve encryption strength of information stored in the user’s cookies. These security keys makes it harder for an attacker to crack a WordPress password.


Why is ASLR not performed at less than page granularity?

ASLR relies on features of the memory management unit of the CPU to map a physical page (i.e. at the hardware level) to an address in the virtual address space (which is the memory layout as seen by the current process). Since this CPU feature only work at the page level it is not possible to get a finer granularity from the CPU. Finer granularity would therefore somehow need to be in software which would be either not possible or terrible slow.


How to handle user token expiration on long running asynchronous jobs?

As always, you have more than one option and the right one depends on the exact scenario, but for example you could either:

Support the OAuth 2.0 client credentials grant in your authorization server so that your back-end services can request tokens on their own behalf without involving the user

(source: Client Credentials Grant)
Support a token exchange mechanism that would allow for a back-end service to exchange the received access token with another one that could allow to call other services using either user impersonation or delegation.

In scenario 1, given that the services could request token whenever required the expiration thing would be a non-issue.

For scenario 2, since the tokens were being issued to back-end services that you trust and would never leave the server-side boundary the lifetime of the token obtained could be much larger than the one used in the access token available to the web application which would also solve your expiration issue.

Also have in mind that scenario 1 would require your services to have the ability to be called either with a user associated token or with a service associated token so this could require some additional logic.

In relation to the refresh token approach, refresh tokens are not usually issued to browse-based applications due to the increased risks of leaks.


Is cookie information hackable by "Man in middle" Attack over HTTPS?

It depends.

Lets say we have a server that only provides an HTTPS service and uses HTTP just to redirect to HTTPS.  The user's browser is authenticated using a session cookie without the secure flag. At some point,  this browser is going to load HTML over plain HTTP by visiting some other domain (http://security.stackexchange.com!),  and then a man in the middle, Eve,  can strike.  In the HTTP response, Eve can injection an image tag that forces the browser to make an HTTP request to the victim server:

...

...

Even though,  victim_server doesn't use HTTP, the browser will make a plain-text HTTP request that can be intercepted by Eve.

So,  to answer the question.  Cookie information can be protected in a MITM attack if the Secure cookie flag is set,  and the application doesn't have other vulnerabilities such as XSS.  There is also the BEAST attack and SSLStrip.


A solution for the absence of Certifying Subkeys in OpenPGP Certs

While I am still looking for an answer here, I have found some clarity on how cross signatures should be done.  I've given a full answer here, but basically, using --default-cert-level 3 would be sufficient.  It would also be necessary to attend to the trust model, which is described at that link.


Reflected XSS script passing through URL how to make it work and what are the preconditions for it to work?

XSS attacks are based upon the fact that input becomes output to the end-user's browser. The most common attack is basically a PHP site containing

<?php
echo $_GET["message"];
?>

You would then pass this URL a parameter containing the javascript code.
If you want to set this up, create a something.php file on your web server, input the above code into it and then access http://your-server/something.php?message= in your browser. It should then display a popup containing XSS.

In a static HTML page, this is not possible, as it only generates content based on the server's static HTML code. XSS needs user-supplied code inclusion. The exclusion is, if the html loads a vulnerable javascript code, that allows user-supplied input.

The primary point of XSS is that an attacker wants to include HIS code to YOUR website, without actually hacking the web server. This is only possible with server-side programming languages, which output something, the attacker previously put into the server.

Basically the hacker wants the HTML to look to the browser like this

Foo

instead of

Foo

Think for example of a forum or comments on an article. The user should be allowed to leave his remarks. The server needs to save this and present the same comment to other users. If the comment itself contains javascript code and the server program does not mitigate this, it would output the same code as part of the comment block.

As to when this is loaded in the browser, this is not easy to answer. It depends on where the hacker's code is included in the page body or the subsequently loaded javascript files. If it is included as a javascript tag in the main HTML, it will be loaded after the DOM load was completed.
Especially as mentioned before, the XSS vulnerability could also happen inside a javascript file (which takes user input, for example a URL and loads it). In this case it is not possible to say, when exactly the code will execute. You could bind this javascript code to a button, a textbox onblur() event or a timer.

EDIT:

Elaborating on the javascript attack, here's what you would put into your server file

The first two lines, bascially take all GET parameters and split them into an array (taken from here). The third line then simply outputs this into the HTML page. Of course this could also be done by any other DOM manipulation from the executed code.


Is it possible for my password to have more than one password combination?

In most password-protected systems it usually is possible, but very unlikely.

Behind many password validation mechanisms is the use of salted hash functions. For the sake of simplicity, let's forget about salt for a moment.

When a user sets its password, hash(password) is stored in the database
When the user logs in presenting password', hash(password') is compared to hash(password). If it matches, the user is allowed to log in.

Let's remember, however, that hash functions get data of unlimited length and transform it to data of limited size, ex. 128 bits. Therefore, it is not hard to understand that there can be more than one message that produces the same hash from a given function. That is called collision and it is what you are concerned about.

The thing is that hash functions are produced to be so random that you should not find or produce a collision easily. It is theoretically "possible", but practically "impossible", if you are using a good modern hash function.


How can other information be added to my credit card?

The magnetic strip on a card is pretty similar to the tape in a video cassette, and doesn't have any particular resistance to being wiped or rewritten, other than generally requiring a stronger magnet due to the specific composition of the material used. Given a suitable writer, therefore, it's possible to write arbitrary data to a card stripe. You can pick up a writer from online stores easily.

Most mag-stripe skimmers can pick up all the data on an inserted card easily enough - historically, they were then used to create dummy cards - so getting the data to write isn't a particular problem either.

The main question therefore is "why would an attacker write different card details onto your card?". I suppose if you wanted to muddle up the trail for investigators looking into card fraud, having multiple people generating transactions for a single card could work, but it also makes determining that it's been cloned easier (can't make in person transactions at locations 100 miles apart within 5 minutes!). Doesn't seem a great reason to me!


Should I be concerned if the "FBI" has logged onto my Ubuntu VPS?

An IP address can be set up in DNS to resolve to any host name, by whoever is in control of that IP address.

For example, if I am in control of the netblock 203.0.113.128/28, then I can set up 203.0.113.130 to reverse-resolve to presidential-desktop.oval-office.whitehouse.gov. I don't need control of whitehouse.gov to do this, though it can help in some situations (particularly, with any software that checks to make sure reverse and forward resolution matches). That wouldn't mean that the president of the United States logged into your VPS.

If someone has access to your system, they can change the resolver configuration which will effectively enable them to resolve any name to any IP address, or any IP address to any name. (If they have that level of access, they can wreak all kinds of other havoc with your system as well.)

Unless and until you verify that the IP address that was used to log in actually is registered to the FBI, don't worry about the host name being one under fbi.gov. That name mapping may very well be faked. Worry instead that there has been a successful login to your account that you cannot explain, from an IP address that you don't recognize.

Chances are that if the FBI wanted the data on your VPS, they would use a somewhat less obvious approach to get it.

You should worry, but not about the fbi.gov hostname.

Go read How do I deal with a compromised server? on Server Fault, and How do you explain the necessity of “nuke it from orbit” to management and users? here on Information Security. Really, do it. Do it now; don't put it off.


How to estimate the cost of an application vulnerability?

The cost is not from the vulnerability but from the risk. Namely:

A vulnerability is that which can potentially be exploited to put at risk your information assets (e.g. a buffer overflow).
A threat is a context element which will try to snoop on or damage your information assets (e.g. an existing group of attackers who would benefit from such actions in some way).
A risk is when a threat meets a vulnerability, and they get along well, and marry, and have offspring.

The cost is something applied to whatever you do with the risk. For instance, the cost of ignoring the risk is, roughly, the cost of the damage resulting from the actualization of the risk. On the other hand, the cost of fixing a buffer overflow is purely development & deployment cost, since it removes the vulnerability. The art of risk management is to strike the right balance between corrective actions and acceptance (the "right balance" being relative to the risk management goals, which depend on the organization).

Bottom-line: cost is about what you do, and depends on a lot of contextual elements, in particular threats. You cannot estimate any meaningful notion of cost without taking the context into account. You cannot attach a cost to a vulnerability, or even to a risk; the cost is a property of a set of actions (since "doing nothing" is such a set, some cost is always incurred).


Is it safe to store twitter access tokens client side?

As with all security considerations it helps to be clear about who you are defending and who you are defending against. Your clients are fairly safe in this environment though perhaps they could mess with you a bit.
Someone could write another twitter client and that client could pretend to be your client. If it misbehaves and Twitter bans it, you could be banned as collateral. This assumes that the Twitter API calls are being made client side so the client needs to have enough information to act on your behalf (from Twitters perspective). If you make all API calls server side and don't share your access codes then nobody can modify your client or impersonate it.

If it makes you feel better most twitter clients have this problem...


What exactly would that image request URL look like?

It need not be anything complicated or abnormal. There are two main ways this could work (were it not for the restrictions in the browser):

In the first, there is a specific URL for the profile image of the current user, say http://mydatingsite.com/currentuser/profileimage.jpg. This might be an odd way to design a site, but I have seen it used. This sort of attack works against anyone logged in, and you do not need a customised URL for your target.
The second works for attacks targeted at a specific user. If I know you are the owner of the check with ID 12345 I could find out what it looks like by using a URL like http://mybankingsite.com/checks/12345.png.

  How does nastysite.com know what specific URL to use?

As an attacker you have to do some research. You can find the URLs or at least the formats of URLs in the source code of the page you are trying to get data from.

  And does it work if the connection you have to the dating or banking site is through HTTPS is part of a particular session?

Not sure what kind of session you are talking about here. But in general it would work as the user is logged in to the site in question in the same browser as they visit nastysite.com in.

  Does nastysite.com have free access to your session cookies for mydatingsite.com and mybankingsite.com? Can it use them in an image request that the mydatingsite.com and mybankingsite.com servers can't tell isn't a normal session request from their own page?

You are right that all this comes down to cookies. You can not read cookies cross origins, so nastysite.com has no idea what your sessionid on mydatingsite.com is. But for this to work, there is no need to read cookies! The browser is kind enough to send cookies on all requests, no matter what origin the request comes from.

If browsers did not mark canvases with cross origin data as tainted, this would be a real problem. You would have a situation similar to CSRF, where all servers needs to have protection in place to stop cross origin mishaps. New features such as canvas should not break backwards compatibility and force all existing sites to adapt. That is why the tainted concept was introduced.

Note that short of browser bugs this is all quite theoretical since browsers should stop this kind of attack.


Is injecting a second Authenticity_Token on a login request considered a security threat?

I believe this attack if successful is called as HTTP Parameter Pollution(HPP) and the ability to inject parameters is called HTTP Parameter Injection.
More on that at:
https://www.owasp.org/index.php/Testing_for_HTTP_Parameter_pollution_%28OTG-INPVAL-004%29

Now, as far as the scenario you described is concerned, in my experience, a lot of servers will allow you to send multiple parameters with the same name such as your 'authenticity_token'. Some servers use the first instance of the value in the request and some use the last depending on the server. I think, the server in your case could be using the first value. But, to verify further and to determine its exploitability, Quoting from the OWASP Link above:

Whether or not this default behavior reveals a potential vulnerability depends on the specific input validation and filtering specific to a particular application. As a general rule: if existing input validation and other security mechanisms are sufficient on single inputs, and if the server assigns only the first or last polluted parameters, then parameter pollution does not reveal a vulnerability. If the duplicate parameters are concatenated, different web application components use different occurrences or testing generates an error, there is an increased likelihood of being able to use parameter pollution to trigger security vulnerabilities.

I think this explains it well. Hope that helped.


Kerberos three transactions -- why not just use two?

It might be right that asymmetric cryptography has much easier steps than secret-key encryption, but there are efficiency barriers such as CPU cycles, complexity of the asymmetric cryptography algorithm and network bandwidth.

Asymmetric algorithms use much more complex mathematics than symmetric algorithm to carry out their functions, which require more processing time and can be extra hit to the Kerberos performance. In addition, asymmetric cryptography must include extra randomness (such as initialization vector, nonce) which makes encrypting messages sometimes bigger than the actual plaintext data size - depends on data size, key size and  complexity of the cryptography algorithm used.

RFC4556 describes protocol extensions (PKINIT). These extensions provide a method for integrating public key cryptography into the initial authentication exchange. However, there are some security considerations mentioned such as:

The security of the overall system is significantly weakened by
using insufficient random inputs.
Kerberos error messages are not integrity protected; as a result,
the domain parameters sent by the KDC as TD-DH-PARAMETERS can be
tampered with by an attacker so that the set of domain parameters
selected could be either weaker or not mutually preferred.
In order to trust a KDC certificate that is certified by a CA as a
KDC certificate for a target realm, the client MUST verify that the
KDC certificate's issuing CA is authorized to issue KDC certificates
for that target realm. Otherwise, the binding between the KDC
certificate and the KDC of the target realm is not established.
PKINIT allows the use of the same RSA key pair for encryption and
signing when doing RSA encryption-based key delivery. This is not
recommended usage of RSA keys and by using DH-based key delivery,
this is avoided.
When the Diffie-Hellman key exchange method is used, additional
pre-authentication data may be dropped or added by attackers without
being detected by either the client or the KDC - which open the door
for insertion of malicious data without being detected.

For more information check these links:

https://tools.ietf.org/html/rfc4556
https://tools.ietf.org/html/rfc4430


How hard should I try to prevent a user from XSSing themselves?

This is actually a real concept, "Self XSS" which is sufficiently common that if you open https://facebook.com and then open the developer tools, they warn you about it

Obviously Facebook is a specific type of target and whether this issue matters to you or not, would depend on the exact nature of your site, but you may not be able to discount the idea of one user using social engineering techniques to get another user to attack themselves.


Could using a generated key from an online service be considered a risk?

Nothing prevents him from storing the password
Yes it is a risk, because you do not know what is happening with the assigned key on the backend of the website

Writing a proper keygen isn't hard, there are many examples on how to write a simple script that does this for you. It's important however that you use the correct amount of entropy for the randomness of the generated key. Please refer to the Bear's answer here.


Data Protection in EU for usage of personal documents

A really good set of examples in Ireland are at http://www.dataprotection.ie/viewdoc.asp?DocID=38. This site provides templates and describes the contract issues that may need to be tackled (your particular country may have a slightly different flavour):

Adherence to data protection rules
Transparency
Cooperation
Liability

This copy of the Directive also gives good guidance, but unfortunately does not provide templates.


Are the privacy features of Firefox 69.0 complementary to PrivacyBadger 2019.7.1.1?

Firefox' new Enhanced Tracking Protection (ETP) does in fact the same what PrivacyBadger does, It blacklists Cross-Site trackers, blacklists cryptominers (although I'm not aware of one), so there is no need to use PrivacyBadger longer. Furthermore you can disable or allow third-party cookies. If you want to use PrivacyBadger anyway then I recommend Browserprivacy set to 'normal mode' otherwise there is a possibility whereby PrivacyBadger features can conflict with Firefox' new features since these protections only apply with Browserprivacy set to strict-mode. Privacy Badger does protect you against canvas-based fingerprinting, Firefox does this also and thus there is a possibility that both can conflict with each other. 1

Two security-guards that do the same is worthless and likely will override the existing security.


What is the best way to protect against a phishing attack?

Phishing is a social engineering trick, so the effective way to mitigate it - is to educate your users. Create a mandatory training courses, buy or create a plugin to outlook or whatever mail clients they are using that can flag emails as phishing attacks and send to you or your team for forensics, contract a third party to sometimes perform a non malicious phishing attack (when you click on attachment it will say "this was a part of our comprehensive phishing awareness programs..." to keep your users aware.


This is a tricky question to answer because GETs might be totally fine, or might be totally broken, it depends on how you've built the security mechanisms on your API. Have a look at the OWASP REST Security Cheatsheet.

In some cases there's no difference between URL parameters in a GET, and body params in a POST. For example, take RFC 6960, the wire protocol for Online Certificate Status Requests (OCSP), appendix A.1 allows the same data to be sent in a POST or a GET (if under 255 bytes), and must be treated the same by the server.

  A.1.  Request

  HTTP-based OCSP requests can use either the GET or the POST method to
     submit their requests.  To enable HTTP caching, small requests (that
     after encoding are less than 255 bytes) MAY be submitted using GET.
     If HTTP caching is not important or if the request is greater than
     255 bytes, the request SHOULD be submitted using POST.

In general though, I think POSTs give you more control over security. For example, many phishing attacks work by getting the user to click on a link. All browsers treat link referrals as GETs, so if a particular resource is only accessible over POST, then it's not possible to do link-based phishing attacks (or, at least, the attack requires multiple steps, like getting the user to click the link and then click a button on the phishing page).

Another win for clean separation between GETs (used only for fetching data in a "Read" type way), and POSTs (used only for modifying or storing data in a "Write" type way) is cross-site request forgery protection [source]:

  In HTTP GET the CSRF exploitation is trivial. For example, a simple hyperlink containing manipulated parameters and automatically loaded by a IMG tag. By the HTTP specification however, GET should be used as a safe method, that is, not significantly changing user’s state in the application. Applications using GET for such operations should be rewritten to use HTTP POST and/or use anti-CSRF protection.

TL;DR1: It's hard to say that switching from a GET to a POST will magically give you more security, because it depends what that API endpoint is doing. POSTs do give more options for how you implement your security mechanisms and a few less attacks to worry about, but with the right understanding and attention to detail you can build perfectly secure GET APIs.

TL;DR2: It's hard to answer your question by itself, out of context of what your API is doing, and what security mechanisms you have in place (CSRF protection? How does you authentication and authorization mechanism work? etc). I would suggest that you read the OWASP REST Security Cheat Sheet and look at your API security as a whole.


Hashing standards in DB front end Software

The standards would not really change from the web to local storage, with the exception of maybe some of the implementation details.  Hashing is still a defense-in-depth technique to protect in the event of a compromised data store for both situations.   The preference are still:

If you can get away with it, don't store anything.
If you need to store a password, hash with a salt using a Key Derivation Function (KDF)


Protecting a private key by spreading it over multiple places

Just splitting the file up will not have the desired effect (as A.Hersean explains in their answer).

I think what you're looking for is "Secret Sharing" algorithms, most notably Shamir's Secret Sharing algorithm (thanks @heinrich5991), where the secret is split up into N pieces and given to different people for safe-keeping. To reconstruct the secret, all N pieces (or in some variants, only k of the pieces) need to be brought together. The attacker gains no information unless they have all the pieces.

Although used in many applications, I don't believe it is available in openssl or CAPI. There are many robust open source implementations -- see this question, but you'll need to do some homework to decide if you trust the implementation to not be back-doored.

There is also the related concept of "Multi-party encryption"; where you  encrypt the secret with multiple people's public keys, and then all of them need to participate in decrypting it. Here's a SO tread about it:

Encryption and decryption involving 3 parties

You can do a poor-man's version of this using only the RSA implementation you already have by chaining RSA encryption:

RSA(key1, RSA(key2, RSA(key3, secret) ) )

If you want 3 people to encrypt, but only 2 of them need to be present to decrypt, then you can store 3 versions of the ciphertext:

RSA(key1, RSA(key2, secret) )
RSA(key2, RSA(key3, secret) )
RSA(key1, RSA(key3, secret) )


Does a Windows 10 endpoint check software installations for malware if they are installed through GPO / SCCM / Software Center?

Instead of waiting for the application getting deployed by SCCM or GPO you should at least apply the below Security measures:

1) Monitor any new application get deployed
2) Monitor accounts that have privileged permission which is used by SCCM
3) Monitor SCCM or AD login attempts
4) Not allow any application to be deployed unless it get approved by Security team
4) For RDP apply MFA

There is also many more, and regarding AV's it will check the signatures once the file land on the hard disk for signatures.
but bear in mind that there is alot of application that can harm your environment that are not detectable by old AV's since they write on Memory sections like fileless malwares and many more so take proactive measures before anything get deployed in your environment.


Maintaining root SSH access on Linux Ubuntu even after losing it?

Persistence

This would be called 'persistence' both from perspective of automated malware and a human attacker.

Some popular approaches include:

Extra user accounts - for example, creating an account 'hacker' with full suid privileges would allow to log in if the root credentials are changed;
Backdoors - for example, a php webshell on a webserver, or a running CobaltStrike beacon, or a netcat bind shell listener would enable future access even if ssh becomes blocked as such. Also, downgrading some system service to an older version with known remote code execution vulnerabilities would be a useful backdoor.
Scheduled tasks - for example, a cron job that runs a reverse shell every hour to an attacker-controlled adress, or a system startup script that adds an extra privileged account and backdoor when a system is restarted would enable to regain access at a later time if the attacker is kicked out.


One user ID of a trusted key has unknown trust

There is a difference between trust and validity. Trust allows keys to validate other keys (so its outgoing signatures extend your partition of the web of trust). Trust means that you trust in the key's owner to reasonably sign other keys. A key is valid if it is in your partition of the web of trust: signed by you, or has acceptable trust paths from your key.

Trust is key based, while signatures are (usually) UID based. Looking at the given output, you probably signed John Doe <j_doe@some.tld> some time ago, but not John Doe <doe@some.tld>.

Sign that UID to make it valid. The trust on the key does not matter here.


Should one not give path parameters in rest urls to avoid man in the middle attacks?

... to avoid man in the middle attacks was to not send IDs in the URLs (i.e. not sending the IDs as path parameter ex. Don't do this : GET /orders/{order-id})

A man in the middle can both manipulate the request header (containing the target URL) and the request body too, so the "protection" to move important information into the body will not help.

  ... Better approach would be to use something like tokens and IDs in the body.

I'm not sure what exactly you mean with this. But if for example the order-id given by the server should be save against manipulation by a man in the middle attacker then protecting it with a signature (token) based on the order-id, the current user session and some server side secret would work. It would be irrelevant if this is used in the URL or the request body though.

Anyway, trying to protect against an active man in the middle by somehow protecting fields is  not sufficient since it only protects information provided  and protected by the server but not by the user (i.e. where to ship stuff etc). Protection against man in the middle attacks should be done with encryption by HTTPS instead.

Protecting server-provided information (like order-id) with signatures is instead a way to protect against attacks where some attacker tries to access data from other users. This is not specific for man in the middle attacks though.


Is it possible to use ROP to call legitimate functions even if the stack is not executable?

That code is a classic example of a buffer overflow vulnerability. Memory corruption is certainly possible in this case, but whether or not it's exploitable for remote code execution or arbitrary function calls depends on which exploitation mitigations are enabled within the binary and on the system, but generally it should be considered vulnerable code.
NX/DEP do not prevent ROP, since ROP relies on executing code that already exists in the program/libraries instead of attacker-supplied data on the stack/heap.


Is it possible that authorities can't block a certain website

As far as I can tell, you’d need to define where it would be “Live Streaming” from. For example, if someone used darknet (Onion/TOR) to stream, it would be very difficult since there are a lot of randomized layers. No one would be able to block a live stream since it would come from various sources (nodes). There could be no mechanism to have ISPs block their clients from viewing it either, as they’d have to block TOR protocols, and it does nothing if someone uses even more proxies to bypass the blocks.

There would be a mechanism to determine who had watched it, based on checksums, length of the stream, and other tidbits investigators could piece together, however that too becomes a touchy subject since they’d literally have to have all ISPs do some form of flow (netflow/jflow) and calculations.

Short answer is, they would be hard pressed to stop it without breaking laws, and violating privacy while doing so.


Is a compromised SQL Server sa account without a domain login enough to access database?

If you have no access to connect to the database, either directly or indirectly, then possession of the 'sa' account credentials on its own is unlikely to be beneficial for attacking the database, as the attacker can't actually make use of them.

However as @paj28 mentions in comments, attackers have a number of ways in that may not depend on an exposed port on the firewall, so if you're asking this question from the perspective of a defender, it could be dangerous to assume that the exposure of the credentials carries no risk.


Can I listen to a remote IP's traffic using Wireshark? (Man in the Middle)

If by remote you mean "on my local LAN but not me" then the answer is possibly;  If by remote you mean "on a remote LAN" then the answer is "No, not with Wireshark."  You'd be looking for something like a network probe with RMON capabilities.

You could use a Span or Mirrored port as Lucas points out or you could force the switch to begin forwarding packets to you in a variety of ways.

Before I continue with more of an answer for possibility #1 let me clearly state that what I am suggesting should be done only with permission and initially in a test environment.  Failure to do so could be illegal, possibly get you fired and maybe even bring systems down.

One method is to begin to send unsolicited arps advertising that the machine whose traffic you wish to sniff is actually located at your MAC address.  Before launching a test of this type, though, you would need to verify that you have enabled forwarding on your system and then actively forward those packets to the original MAC address.  This can be achieved by creating a static ARP entry in your local ARP table for the host that you are sniffing.  If you fail to do this then your system will "eat" the packets and the host you are sniffing will be unable to receive packets.

A second method is to simply generate very large numbers of unsolicited ARP responses, seeking to override the CAM table in the switch.  These typically max out at about 4096 addresses.  Depending on the device the switch will now begin to broadcast all traffic to all ports.

A tool such as Yersinia or Ettercap can be used to effect both of these strategies.


Yes, a DjVu file can be dangerous. While, as others have mentioned, it is designed not to have any executable code, a vulnerability in a DjVu parser can be used to exploit the viewer. Many viewers use the same library, making a vulnerability in a single library relevant to large number of viewers. A historical example is CVE-2012-6535, which affected the popular DjVuLibre library, used by many document viewers. The vulnerability, as reported by Microsoft, was a memory corruption bug that allowed for code execution. The CVE details page gives some general information about its impact:

DjVuLibre before 3.5.25.3, as used in Evince, Sumatra PDF Reader, VuDroid, and other products, allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted DjVu (aka .djv) file.

Unfortunately, it is not possible to manually detect a malicious file of this sort. They do not necessarily contain any tell-tale signs such as visible embedded scripts or suspicious strings, and antivirus will rarely be able to detect them. In fact, they usually skip files that are not executable.
This is not at all specific to DjVu. Any file format can be exploited, even ones you don't expect. The best way to reduce the risk of exploitation is to ensure all your software is up to date, so any discovered vulnerabilities are promptly fixed before they can be widely exploited.


What could happen if regex metacharacters using named capturing group are not encoded?

Technically yes, there is a very minor data leakage vulnerability here.

In your example:

"aaaaaafooNfooaaaaaaa".replaceAll("foo([A-Z])foo", "user_input")

if user_input contained $1 and the value of the above was output and the input string aaaaaafooNfooaaaaaaa was not user controlled, the user would be able to find out what the original "secret" string was (i.e. the N).

Practically the answer is really no, unless someone has been deliberately "unusual" with their coding.


Can a root user inside a Docker/LXC break the security of the whole system?

Short answer: Root on the docker container can break out of jail and compromise system.

Docker is meant to simplify the life of developers and sysadmins, not about containing programs isolated from each other. There's some safety features backed in, but they are not the main intention. The idea is to ship a container with the application and every pre-requisite packed together and let the user start it without hassle, not to keep misbehaved users or applications in check.

There are some exploits that make possible to a user running root applications inside a container to break free from the container and compromise the host. Docker took some measures to fix those loopholes, but they are cumbersome to employ.

This Docker security article tells you to not let users load modules. To allow module loading you allow the user to easily break free of the jail. If you want security AND let people load modules, use a VM.

You can create light virtual machines using Xen, VirtualBox or Kvm, and they will be isolated from each other. You can give all your users root on the image, and they will not be able to mess with each other nor with the host system.


Forcing IE11 to use perfect forward secrey on AWS ELB

IE11 supports TLS v1.2, v1.1, and v1.0, so it should be able to use one of the configured ciphers, right?

No. The only cipher suite mandated by RFC 5246 is (in OpenSSL parlance) AES128-SHA. (I don't think any later RFCs added more.)

Read the SSL Labs client reports for IE 7/Vista and IE 11/Win8.1. IE supports DHE -- but only with DSA certicates. However, it does support ECDHE with RSA (and ECDSA) certificates.

You need to enable a cipher suite supported by IE, as listed above by SSL Labs. IE 7-10 support TLS 1.0 and the cipher suites ECDHE-RSA-AES128-SHA and ECDHE-RSA-AES256-SHA. IE 11 also adds support for TLS 1.2 and ECDHE-RSA-AES128-SHA256. If the ELB platform doesn't support ECDHE, your only option is to enable some old non-PFS cipher suite like AES128-SHA.


Why is Elliptic Curve Cryptography not used much outside of government?

There are a lot of reasons why ECC is not used more widely, among which are:

ECC is newer than RSA and Diffie-Hellman (by about a dozen years).
ECC mathematics are a bit harder to grasp than RSA/DH maths. Most people should not implement cryptographic algorithms anyway (safe cryptographic implementation is hard; it is much better to rely on existing libraries), but developers really prefer to use algorithms that they could theoretically implement themselves (they want to feel that they understand what is going on).
ECC has been covered by some patents. Since patent law is a difficult subject which is typically not well known by people who specialized on cryptography (because it is another specialization), the generic attitude is that of cautious distrust.
RSA was there first, and is firmly entrenched. If you want wide usage of ECC, kill RSA first.

You do not tell which government mandates use of elliptic cryptography, so I guess you are talking about the US government. At one point, the US government paid a hefty sum to Certicom (something like 25 millions of dollars) for the right to use the techniques covered by the patents held by Certicom. It is no wonder that they want to use them, then.


Methods of cold boot attacks in the wild

First I want to address the DDR3 vs DDR4 issue.  The differences between DDR3 and DDR4 are mostly voltage and clock speed.  I've looked to see if there's any research on cold booting DDR4, and so far it looks like there's no academic papers out concerning their practicality.  While commercial forensics labs may be performing cold boot attacks on DDR4 they're not likely to publish their techniques as that's their competitive advantage. Then again the differences between 3 and 4 are relatively minor (no major changes to what it does, rather it's how it does it's job).  It could be the case that there's no difference (in terms of cold booting) between DDR3 and 4.

Cold booting DDR1/2 (in 2013 they couldn't get into DDR3)
https://www1.cs.fau.de/filepool/projects/coldboot/fares_coldboot.pdf

Cold booting DDR3 (Intel scrambling)
https://www.dfrws.org/2016eu/proceedings/DFRWS-EU-2016-7.pdf

Cold booting DDR2 & DDR3 differences (2015) - DDR3 10 second power loss shows very low error rates in recovery.
https://youtu.be/ZHq2xG4XJXM?t=13m10s


Why the ARP entry of the router recover so quickly after ARP poisoning?

Every time a host wants to communicate with another host on a local area network segment it must somehow determine its physical address (this is what a MAC address is, after all).

The process of physical address resolution occurs with the ARP protocol. This process consists of an exchange of ethernet frames in order to map logical addresses to physical addresses (most commonly, IP addresses to MAC addresses).

Now if this process happened every time 2 hosts wanted to exchange data on network segment, this would negatively impact the network performance -especially in cases where there is a large number of hosts that constantly communicate with each other.

To solve this problem, networked systems cache the physical address entries locally for a certain period of time. This way, each time a system wants to interact with another system on the local network, it looks up the physical-to-logical address mapping in a table stored in its memory. This is much, much faster than the address resolution process mentioned earlier.

The entries in the ARP cache are not permanent, though. They have a certain lifetime and once it expires they are refreshed again through a new ARP lookup. This method minimizes the global number of ARP lookups required for communication and at the same time keeps the logical-to-physical address mappings up-to-date.

In order to "preserve" an ARP Man-In-The-Middle situation, you need to constantly spoof the MAC addresses in order to keep them in the ARP caches of the targeted systems for the duration of the attack.

The lifetimes of ARP cache entries are implementation-dependent and vary from operating system to operating system.

You mentioned that you didn't see any "packets" in Wireshark, therefore I assume you were capturing IP traffic. The ARP look-ups occur on a lower level (Layer 2) and it uses ethernet frames and not IP packets for data exchange.


Do vBulletin and similar discussion forum CMS store previous email address and password hash in database?

Many off the shelf bulletin board and similar forum software are simplistic enough to not store history of changes. However some are more complex and do.

One way to positively identify ones that do (although the reverse is not true, this will not prove a negative) is to change your password to something, then try changing it back to the original. A good password change function will not allow you to re-use the most recently used n password hashes as this is a common user security compromise. If the system is able to block that behavior, then it is keeping password hashes.

As a rule of thumb, you can bank on their being some history out there, not necessarily from the website software itself, but from server backups. Anybody who snapshots their servers or runs regular dumps on their databases for backup purposes is going to have a some records with your old info floating around somewhere. The likelihood of these ever turning up anywhere is low, the as an end user your chances to find and eliminate them are even lower.


Is it secure to distribute Certificate Revocation Lists over HTTP?

HTTPS (or any TLS clients really) need to know the certificate revokation status before being able to trust that TLS connection. If the HTTPS connection used to fetch the CRL itself can't be trusted, then what is the point? Not to mention, your original HTTPS connection triggers a CRL lookup, which in turn triggers another HTTPS connection for the CRL server, which in turn... you get the point, we end up with an infinite loop of resource-expensive, untrustable and thus pointless connections.

Fortunately CRLs are signed themselves so the transmission medium doesn't matter, it must on the contrary be as lightweight as possible, so that excludes HTTPS (or any other crypto protocol really).


What clients are proven to be vulnerable to Heartbleed?

As a matter of fact, yes, clients are vulnerable. So far the attention has been focused on servers as they are much more open to exploitation. (Almost) everyone can connect to a public HTTP/SMTP/... server.

This blog describes how the bug actually works (it mentions dtls_process_heartbeat(), but tls_process_heartbeat() is affected in the same way). This function is used both for clients and server applications, so indeed clients should be vulnerable too.

According to RFC 6520, heartbeats should not be sent during handshakes. In practice, OpenSSL accepts heart beats right after the sending a ServerHello (this is what Jared Stafford's ssltest.py does). Upon further testing, I have discovered that servers can abuse clients by sending a Heartbeat right after sending the ServerHello too. It triggers the same bug.

A proof of concept can be found in my repo at https://github.com/Lekensteyn/pacemaker. From its README:

  The following clients have been tested against 1.0.1f and leaked
  memory before the handshake:

  MariaDB 5.5.36
  wget 1.15 (leaks memory of earlier connections and own state)
  curl 7.36.0 (https, FTP/IMAP/POP3/SMTP with --ftp-ssl)
  git 1.9.1 (tested clone / push, leaks not much)
  nginx 1.4.7 (in proxy mode, leaks memory of previous requests)
  links 2.8 (leaks contents of previous visits!)
  KDE 4.12.4 (kioclient, Dolphin, tested https and ftps with kde4-ftps-kio)
  Exim 4.82 (outgoing SMTP)

It has been demonstrated that 64 KiB of memory (65535 bytes) can indeed returned. It has also been demonstrated that clients (wget, KDE Dolphin, ...) can leak data like previous requests possibly containing passwords.


Are services who offer to pay you a rent for your unused hard disk space a scam, and how do they work?

Can this be for real?

You have already done the math: $200 would buy 4TB of storage space, and half that sum again will connect it to the Internet with an (almost) unlimited bandwidth for one month. Supposing twenty months' life expectancy for the hard disk for ease, we get around 30 USD per month per terabyte with a DIY scheme.

Since your PC is unreliable, whoever rents it for "cloud storage" would need to use a Redundant Array of Inexpensive Donors :-). Also, they'd need a complex RAID-10 architecture to cope with the fact that most people is connected with asymmetric DSLs, so they can't upload at the same speed that some "cloud user" is needing and willing to download.

All in all, for the system to even begin to be feasible you'd need to the tune of ten physical terabytes for every logical terabyte you offer, while with a "real" disk you'd be almost one on one.

And with these ten terabytes donated by the common guy, they need to compete with DIY cloud services at 30 USD per month.

Actually they're competing with even less expensive professional outfits such as Amazon and their level of economy of scale (and service level agreements. You have to undercut their prices by a hefty margin to convince someone to store their files in what I'd call Fog Storage).

So if they offer to pay more than around 3 dollars a month for a whole terabyte, they cannot be after storage space to offer to the cloud at market prices.

The syllogism (some might-be-legit options)

The above syllogism can be falsified several ways, not all of them leading to a "it's a scam" or "illegality" sentence.

if they offer to pay...    : they might not offer to pay anything of real value to them (i.e., they don't have this cost), but supply some other advantage to get people to join. A fair exchange of disk space on other people's computers for example: you're their backup, they are yours. The users, not the service guys, are actually those "paying" each other. The business model then must rely on some other source of income: a participation fee, targeted ads on the file client, in-app purchases, and so on. Or they might just hope to be bought by Amazon for a jillion bucks, or become a FaceDrive.

more than: they might pay less (and use the same business model than above). Mind you, this is not money for nothing. Disk usage costs something. Extra resource consumption does not only impact "unused" disk space and "unused" bandwidth but also energy. If you earn US$ 5 per month and end up with a utility bill increase of US$ 6, their gain (they did not have to pay for electricity to keep the disks spinning and the drive heads seeking) is your loss. This is somewhat akin to cryptocoin mining: the coins you mine aren't free, they're mostly paid with increased electricity bills.

cannot be after storage space: they could be after something else. See below.

to offer to the cloud at market prices: this particular configuration of storage space might have advantages for someone, and be worth much more than standard market prices. There might also be reasons why the same configuration isn't offered by industrial services such as Amazon, so this particular option could be a seller's market.

So what might they be after (the don't-do-that option)?

Well, for the contract that turns your PC's hard drive space into a cloud storage to work, the following things should be granted and found perfectly unsuspicious:

access to your hard disk. Oh yes, only the unused areas (look there: isn't that Santa Claus?).
capability of sending lots of data on the Internet. Anywhere (our customers are anywhere!) and you can't see what that data actually is, it's encrypted (our customers value their privacy!).

Just the two things above are enough to:

scan your whole hard disk and look for home banking credentials, credit card details, all sorts of valuable personal information and so on.
turn your PC into a spamming relay.

Both these "features" would be quite valuable to someone, and they might be amenable to pay good money.

Especially since they needn't pay you anything. After one month service they can just disappear or say your services weren't up to spec. They might even ask for a fee to waive end-of-contract full hard disk sanitization (i.e. cancellation) as specified in a contract not everyone would read or understand. Or they might increase resource consumption so much on your machine, that you will ask for cancellation (and therefore be uneligible for any refund).

Another possibility is that the piece we're missing is "storage space at market prices". What if it's a different market? What if what they're after is completely untraceable disk storage, placed in dozens of separate private homes overseas, very difficult to even track, let alone seize or impound? Again, I can think of several people who would pay good money in order to gain this level of protection. What they would store on this fragmented data space is better left unthought.

And it still would be possible to lower costs by not paying the disk donors. Any software architecture that's capable of dealing with people turning off their PC's whenever they like (and they're saying this architecture exists, and they're using it) is ipso facto capable of dealing with people turning off their PC's because it dawns to them they're being ripped off. Therefore, I can't say that it is, but I believe that ripping off people could be a viable business model.


OAuth2 for mobile apps with confidential backend client (Is PKCE required?)

The flow you describe is exactly what Google offers for mobile apps : https://developers.google.com/identity/protocols/CrossClientAuth

After looking in more detail the rfc 6749, we can note that this flow does not respect the recommendations.

https://tools.ietf.org/html/rfc6749#section-4.1.3

  The authorization server MUST:

  o  ensure that the authorization code was issued to the
  authenticated
        confidential client, or if the client is public, ensure that the
        code was issued to "client_id" in the request,

Indeed, the authorization code was issued to the native app, and it is the web application that tries to exchange the code.

It is up to the developer to decide if he wants to strictly respect the RFC and in this case use the flow Authorization code with PKCE then send the access token to the backend server so that it can access the resource server; or if he wants to use the same flow as google.


That looks like a real XSS vulnerability, and I do think you should report it.
To get around the problems with the quotes, simply pass a number instead of a string to the alert function, e.g. alert(1). That way, you don't need the quotes but you can still demonstrate that JS is executed. That should be enough to prove that the vulnerability is real.
If you really want the alert to say XSS, you can create strings without using quotes like this:
String.fromCharCode(88) + String.fromCharCode(83) + String.fromCharCode(83)


How to generate a MSK from IEEE 802.1X-2010

MSK
Each EAP method specifies (actually may specify) its own way to derive a MSK.
This means you have to look in the specification of the EAP method you are using in order to know of the MSK is derived.
Relevant wording from RFC3748:

Master Session Key (MSK)
Keying material that is derived between the EAP peer and server
and exported by the EAP method.

Here "exported" means that the EAP method produces the MSK value and make it available to the lower-layer protocol (eg. the Wifi stack).
An example: EAP-TLS
For example, let's look at EAP-TLS. EAP-TLS works by conducting a TLS (≤ 1.2) handshake over EAP.
At the end of a standard TLS handshake, a master secret is generated as:
master_secret = TLS-PRF-48(pre_master_secret, "master secret",
                    client.random || server.random)

This key material is a shared secret between the two TLS peers.
When using TLS for tunneling data, this shared secret is used to [generate)(https://tools.ietf.org/html/rfc5246#section-6.3) secret keys and initialization vectors for encrypting and authenticating (MAC) the data.
In EAP-TLS, this shared secret is instead used to derive the MSK:
Key_Material = TLS-PRF-128(master_secret, "client EAP encryption",
                     client.random || server.random)
MSK          = Key_Material(0,63)

RADIUS
Now, when you are using RADIUS, the Wifi AP needs the MSK in order to derive the keys used to secure Wifi communications. However, the EAP actually happens between the EAPOL supplicant and the RADIUS server: the RADIUS server needs to communicate the MSK to the Access Point.
AFAIU, this is done by using the MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes from RFC2548 as explained in RFC5216:

The MSK is divided into two halves, corresponding to the "Peer to
Authenticator Encryption Key" (Enc-RECV-Key, 32 octets) and
"Authenticator to Peer Encryption Key" (Enc-SEND-Key, 32 octets).

Enc-RECV-Key = MSK(0,31) = Peer to Authenticator Encryption Key
                  (MS-MPPE-Recv-Key in [RFC2548]).  Also known as the
                  PMK in [IEEE-802.11].
Enc-SEND-Key = MSK(32,63) = Authenticator to Peer Encryption Key
                  (MS-MPPE-Send-Key in [RFC2548])


How does a PHP application get nulled and how to avoid it

You are making the assumption that an attacker would only break the protection methods in an application for financial reasons. This isn't accurate - for a very long time, software cracking of this kind has been done for kudos, to show skills, or just for fun. Adding more layers of protection can even entice more people to try, since there is additional kudos from breaking a difficult challenge - just like people tend to be more impressed by difficult feats, such as climbing Everest, than mundane ones, such as climbing the stairs, even when the underlying action is very similar (and yes, I know that climbing Everest is difficult, but I'm making a point!).

As for different types of protection:

obfuscated code - if I just want to run it, doesn't matter. Once I've got a copy of the code, can use it without needing to know what it actually says. If I want to modify the application, it makes things harder, since I'd need to deobfuscate it, work out what information from variable and function names was missing, then make my modifications. You can always deobfuscate code, given sufficient effort.
license key activation - if I've got access to the full code, for example, by breaking into a server of a company who paid for it, it doesn't matter. You can track whose copy got stolen or shared, but that's a legal thing, rather than a technical thing.
persistent internal validation - ah, now we're getting to fun things. Either I can change all the places you've embedded the domain name after reverse engineering the encryption, which sounds like a lot of effort, or I can find where you call the verification routines, and either change them to return that it is always valid, or just remove that code.
periodic external validation - this one breaks some potential uses of the code. For example, it's reasonable to have a firewall rule preventing outbound connections on an internet facing server for the web server user - it means that if someone does break in, it's hard for them to use my server to send spam, say. Your software won't work on it though. To crack it, either deobfuscate and remove the code, or provide my own validation layer, so that users can add your server name to their hosts file, and get a response from localhost saying "valid" in whatever form you request.


Personal Information available on shared network drive

The bigger question is if this violates the data protection laws of various jurisdictions (it does). From this perspective, you have not secured PII and it's a violation.

For instance, no one, NO ONE has any right to know how old I am. I do not want to be subject to discrimination, and my birthday is private information. If I found out that my employer posted that info internally, I would be calling up the meanest lawyer I knew.

No one needs to know this info except for HR, which means if it was posted, then is not being used for the purpose that it was collected.


Which has to handle certificate, a website, a web server or a web application?

A Web Server handles certificates and TLS connections

A web site itself is simply an HTML document, possibly including scripts and stylesheets, and references to other resources (external scripts, styles, images, etc.). The document itself is not aware if it is served via HTTP or HTTPS, and if so, which certificate was used for that.

Instead, these things are handled by the web server. A web server, such as nginx, can be given a certificate and the private key associated with the certificate. If configured to server HTTPS, then the web server will use said certificate in any incoming TLS connection.

Regarding Multiple Certificates

You seem to confuse "web site" for "web server", in regards to nginx. A web site is one document, where as a "web server" is one logical unit for nginx, with its own configuration and, more importantly, host name.

As such, nginx can be configured as follows:

server {
    listen 443;
    server_name server1.example.org
    ssl_certificate cert1.pem;
    ssl_certificate_key key1.pem;
}

server {
    listen 443;
    server_name server2.example.org
    ssl_certificate cert2.pem;
    ssl_certificate_key key2.pem;
}
...

If the web server was reached with the hostname server1.example.org, it would serve the certificate found in cert1.pem. Likewise, if it was reached as server2.example.org, it would server the certificate from cert2.pem.

Regarding Web Applications

Likewise, a "web application" is just a fancy name for a document with some server-side logic behind. But this also does not handle any certificates or TLS connections. In fact, it would make a web application a lot less portable if it did so, because any change in certificate would require changes to the codebase.

This split was done intentionally, as it separates two different tasks. The task of the web server is to accept incoming connections, parse HTTP requests, handle TLS connections, etc.. Once all of this is done, the web server forwards the parsed requests to the web application, which then handles all the application logic.