There are a number of strategies, each having their own costs and benefits. Here are a few (there are more, and variations):

blackholing

By blackholing traffic, you discard all traffic towards the target IP address. Typically, ISP's try to use RTBH (remotely triggered blackholing), by which they can ask their upstream networks to discard the traffic, so it won't even reach the destination network. The benefit here is that it will not saturate the ISP's uplinks then. The biggest drawback here is that you do exactly what the attackers want: the target IP address (and thus the services running on it) is offline. However, the rest of the ISP's customers will not suffer from the attack, and the costs are low.

selective blackholing

Instead of blackholing an IP-address for the entire internet, it may be useful to change BGP routing for the targeted address range so that it's only reachable for parts of the internet. This is typically called 'selective blackholing' and is implemented by a number of large carriers. The idea is that many internet services only need to be available in a specific region (typically being a country or continent). For example, using selective blackholing, a Dutch ISP under attack could choose to have it's IP-ranges blackholed for traffic coming from China, while European IP's would be able to reach the targeted address. This technique can work very well if attack traffic is coming from very different sources than regular traffic.

scrubbing

A nicer solution is to use a scrubbing center, usually hosted outside the ISP's network as a service. When under DDoS attack, the ISP redirects traffic for that IP-range to the scrubbing center. The scrubbing center has the equipment to filter unwanted traffic, leaving a stream of (mostly) clean traffic which gets routed back to the ISP. Compared to blackholing this is a better solution since the services on the target IP remain available. The drawback is that most scrubbing centers are commercial, and can cost quite a lot. Also, scrubbing is not always easy, there can be both false positives (wanted traffic being filtered) and false negatives (unwanted traffic not being filtered).

traffic engineering

ISP networks usually have a number of connections to the internet via transit providers and/or internet exchange points. By making these connections, as well as links within the backbone of the ISP, much bigger than is needed for normal traffic patterns, the network can cope with DDoS attacks. However, there's a practical limit to this, since unused bandwidth capacity is costly (for example investing in 100Gbps equipment and upstream connections is very expensive and cost-inefficient if you're only doing a few Gbps) and this usually only moves the problem to somewhere within the network: somewhere there will be a switch, router or server with smaller capacity, and that will become the choke point.

With some attacks, ISP's may be able to balance incoming traffic in a way so not all external connections will be flooded, and only one or a few will become saturated.

Within larger networks, it's possible to create a "sinkhole" router which only attracts traffic for the IP-range under attack. Traffic towards all other IP-ranges gets routed over other routers. This way, the ISP is able to isolate the DDoS to a certain degree by announcing the targeted IP-range in BGP only on the sinkhole router, while stopping announcement of that IP-range on other routers. Traffic from the internet to that destination will be forced through that router. This may lead to all uplinks of that sinkhole router being saturated, but uplinks on other routers will not be flooded and other IP-ranges will not be affected.

The big drawback here is that the entire range in which the targeted IP is (at least a /24) may suffer from this. This solution is often the last resort.

local filtering

If the ISP has enough capacity on its uplinks (so they won't be saturated), they can implement local filtering. This can be done in various ways, for example:

adding an access list on routers rejecting traffic on characteristics like the source address or destination port. If the number of source IP-addresses in an attack is limited, this can work efficiently
implementing traffic rate limiters to reduce the amount of traffic to the target IP-address
routing traffic through local scrubbing boxes which filter unwanted traffic
implementing BGPFlowspec, which allows routers to implement an exchange filter rules using BGP (for example: 'reject all traffic from IP-address X to IP-address Y protocol UDP source port 123')

content delivery networks and load balancing

Web hosters can use content delivery networks (CDNs) to host their websites. CDNs use global load balancing and thus have enormous amounts of bandwidth and caching server clusters all over the world, making it hard to take down a website completely. If one set of servers goes down due to a DDoS, traffic gets redirected automatically to another cluster. A number of big CDNs also operate as scrubbing service.

On a somewhat smaller scale, local load balancing can be deployed. In that case, a pool of servers is available to host a website or web application. Traffic gets distributed over servers in that pool by a load balancer, thus increasing the amount of server capacity available, which may help to withstand a DDoS-attack.

Of course, CDNs and load balancing only work for hosting, it doesn't work for access ISP's.


Uploading sensitive data, Should I user memoryStorage (buffer) or save and delete file?

In general memory-only leaves less cruft behind, particularly if you explicitly overwrite the memory when finished, assuming you can handle it all in memory.
Deleted files are recoverable to a large degree, but then again so is the mySQL content.
Realistically I think other factors are the main issue. How are you protecting the server and its content independent of the upload handler.


TCP/IP and firewall bypass security risks

Right before the statement you quoted, the author writes:

  Architecture is also shaped by considerations of how best to use our scarce developer time. With a small team of developers, we do not have the resources to do, for example, the in-depth analysis of security loopholes that teams working on Firefox and Thunderbird do.

This is key to understanding what they mean here. Audacity doesn't provide a "route to bypass a firewall", but as a small team they understand that they do not have the man-power or resources to find all the issues in their software that might lead to an exploit that allows people to bypass firewalls.

So rather than putting their resources to work finding holes and bugs in their own software, they avoided the TCP/IP stack altogether, and because of that, avoided a whole slew of security issues that could stem from including TCP/IP.

As far as your second question is concerned, as @schroeder mentioned, that is more of a basic networking question that is not within the scope of this site.


This is likely due to the fact that the certificates used by the apps are pinned. This way breaking the TLS connection with a proxy fails.

It works in your company because the traffic is proxied, but not decrypted/reencrypted - the app does a direct CONNECT call to its server.


Example of how the remaining shellshock bash bug CVE-2014-7169 (taviso bug) could be exploited?

According to @taviso original post, the line

env X='() { (a)=>\' sh -c "echo date"; cat echo

is be sufficient to bring the shell to an inconsistent state. I tried it and after that, things are broken until you close that shell instance. Commands won't be interpreted correctly, parameters are treated like they are out of place unleashing incorrectly reported syntax errors, "man" shows an empty page, etc...


How do I constrain Windows Smartcards for AD Authentication so that "anyExtendedKeyUsage" is not implied?

On a general basis, you cannot enforce a constraint such as "should be used only for smartcard logon". This is supposed to be the role of the Extended Key Usage certificate extension; see RFC 5280, section 4.2.1.12:

  If the extension is present, then the certificate MUST only be used
     for one of the purposes indicated.

But this relies on all applications which validate certificates to actually check the EKU and enforce its contents (an application is supposed to check whether the EKU is there and contains its own OID, or the special anyEKU OID; or, at least, the EKU extension should be absent, if the application does not have a specific OID for itself). In practice, applications do not perform such checks. Some applications will do such processing, but you cannot reliably expect all applications to do it, even if you restrict yourself to the pure Microsoft world.

To enforce separation of roles, you really need several PKI (EKU ought to do it, but in practice it does not, which is sad). To some extent, you could make "one" PKI (i.e. one root) and use distinct sub-CA, and you set the subordinate CA themselves as roots (e.g. you would push the sub-CA specific for smartcard issuance as the "root" in the NTAuth store on the Active Directory server). Such sub-CA are root CA in disguise, so you had better handle them as such (e.g. make them long-lived).

In general, enforcing non-usage of issued certificates is a fruitless quest. To cover yourself in a legal way, it suffices to publish a Certification Policy Statement, duly linked to from the Certificate Policies extension in the certificate, where you state in plain words that the certificates are meant for smartcard logon only. It is not needed (and not really possible either with 100% reliability) that you arrange for all other existing software to reject your certificates. Ultimately, any application can validate certificates as it sees fit.


That is the basic idea, but you probably don't want to implement a custom solution. Depending on your operating system there is probably already a mechanism, for example Debian's SecureApt which leverages GPG.

https://wiki.debian.org/SecureApt


Should all local users with the same username have the same UID in all the machines of an organization?

It's not necessarily required. Having said that, there is not enough information provided to see the full picture of where the thin clients come in touch with the servers. You can do that for the sake of easily aligning all Java applications and users under the same uid. If however, the thin clients mount the remote directories from these servers ( nfs maybe), then matching the GID and UID does help in access management.

Normally, to control the UID and GID allocation, you will have some sort of directory setup like ldap or Active Directory or something similar. On the other hand, if you have a decent configuration management system like ansible, or puppet, you can then control it (akin to deploy) using scripts.


What access does UK Police currently have to ISP logs, and what information can said logs provide?

There's a decent article on the BBC on this type of information here: http://www.bbc.co.uk/news/technology-17586605

In terms of what they'd get from an ISP, the likelihood is that it would be what they accessed and when, search results, search terms etc. However, the contents of online conversations wouldn't be available though they might be identified in on-line forums, blog posts, comments etc. Also, all information posted to Facebook would be available - police have to request this access. If it can be identified who the protagonist had Skype conversations with, I'm sure the history could be restored - this would likely require a warrant with Microsoft rather than the ISP. They should also be able to get access to online email accounts such as hotmail/gmail/yahoo by serving warrants to those parties.

Another article : Google report reveals sharp increase in government requests for users' data - http://www.guardian.co.uk/technology/2012/nov/13/google-transparency-report-government-requests-data

The length of time for which the police will be able to retrieve ISP logs is debateable though it's like this won't go back more than a few months so, if your protagonist's relationship isn't recent, the trail could go cold!


Does flushing DNS help with your anonymity?

Caching is done in DNS on multiple levels. If a browser queries the (usually automatically) configured DNS server the answer is cached for some time in the browser so that it does not need to lookup again the same domain immediately. It is also cached for some time in the DNS server and if this one has an upstream DNS it is already cached there etc. Such caching means that any clients behind the specific DNS server gets the response faster.

The time to do the DNS lookup for a specific domain could be measured by the page embedding this resource. One could thus find out if a specific user has visited a specific domain recently (cached in browser or OS) or if some user of the same caching DNS server has visited the resource (cached in next DNS server) etc. This could be used to find out which sites gets visited regularly by the user (i.e. which are cached in the browser or OS) and thus create a profile of the user.

The caches could also be used to store user specific results for selected domains in control of the adversary and then detect a specific user depending on the IP address (under control of the adversary) he visits when embedding a resource from this domain. To cite from Technical analysis of client identification mechanisms - Lower-level protocol identifiers:

  Such caches can be easily leveraged to store small amounts of information for a configurable amount of time; for example, with 16 available IP addresses to choose from, around 8-9 cached host names would be sufficient to uniquely identify every computer on the Internet. On the flip side, the value of this approach is limited by the modest size of browser DNS caches and the potential conflicts with resolver caching on ISP level.

On the other hand, caching of DNS lookups is important for fast web surfing. Given that there are many other (and often easier) ways to track the user (see again Technical analysis of client identification mechanisms) regularly flushing the DNS will probably not help a lot with privacy.


What is the simplest safe way to convey a password to another person?

I too have tried to come up with a good solution for this. But I found https://onetimesecret.com/ which works great.

Basically you create a link containing a password and you send this link to the intended recipient. As soon as the receiver clicks on the link, the link expires and the password is deleted. So the receiver only has one time to copy the password. A one-time secret.


why do you want to provide shell-access? if it is something like services-restart or defined task that might be executed via scripts, use a simple, shell-based task-manager that allows only defined actions (or better, use a tool like rundesk/jenkins to provide the same tasks to you clients via webinterface)

if you need full shell-access, well, either chroot or live with the consequences :)

regardings ssh:

make sure your keys are pw-protected
generate keys yourself, if you can
forbid pw-login
put ssh onto another port if possible
use sudo and tight NOPASSWD - definitions, e.g restrict to /etc/init.d/apache reload instead of /etc/init.d/apache2  which would allow stop too

your umask 027 might break stuff, expecially if you allow fileupload via scp.


How would one make a network resistant to the unknown?

You've hit on the basic premise of IT Security: you can't predict or stop everything, and to try might cost more than what you are trying to protect. Your character is concerned with Mastery of skill to overcome higher-level obstacles, but the race to create obstacles that are higher than other people's skills is foolish in reality.

In reality, you need to ask other questions. What needs protection? What's the risk severity? What's the risk probability? What could be compromised without concern? How are the assets accessed? How can you employ CIA against those assets? You then lower the risks, probabilities, and costs to levels below the costs of the loss of assets.

To address your question directly, your concept of an all-powerful 'technomage' is fine, but it is easily countered with the idea of 'formlessness'. If you build a fortress, you can attack a fortress. However, if you are air, there is nothing to attack. The more you create 'defence in depth' with higher walls and tougher rules, the more fragile it becomes. An adaptive and regenerative system, on the other hand, is resilient to attacks. Least-privilege principles, internal honeypots, monitoring traffic leaving every node in the network, and classifying every piece of data that is to be protected will get you further than innovative design. (of course, all those things are considered 'innovative' by many)

Edit
By 'formlessness' (read The Art of War, Tao Te Ching), consider not having an all-power Admin on the network. Users, even administrators, should only have enough power to do their jobs and no more. When they need more power, give it to them to do the job, then revoke. No Admin means no Admin powers to usurp.


How can I find out what's in this NASA JPL "Spy" command line program for macOS and how safe it is?

spy.ug is a readme-like text file that displays in my browser, but spy downloads what  Finder tells me is a text document.

It is not a text document. It is a Mach-O 64-bit x86_64 executable.

How can I find out what's in this NASA JPL "Spy" command line program for macOS and what it does exactly in terms of security issues?

You could spend a long time learning how to reverse engineering Mach-O executables and then spend a long time reverse engineering the Mach-O executable.

How can I find out how safe it is?

Do the above analysis which will take a long (long) time.
Alternatively, if you have any contextual information that might allow you to make an informed decision without going through all the binary reverse-engineering analysis, maybe you could try that approach.
Alternatively, you could run the file on a virtual machine and check to see if it starts on virtual fire, or whatever.


How does a malicious user connect to a private network?

I believe they mean that at the endpoints of the communication, you need to practice good security.  The private network only protects data in transit, not at the end-points.

All the computers that connect to the private network need to be secured using standard operating systems security tools.


How to authenticate a specific client program?

You cannot ensure that the program talking to the server is your program. Anything client-side can be compromised, and any communication coming from the client can be altered.

The multiplayer game industry is facing a decades old battle against the kind of problem you stated, and even with millions in funding, expert programmers and a lot of money at stake, they cannot prevent people from using custom client software to interfere with their systems.

  some secret has to be compiled into the executable

And the attacker can extract this secret, reverse-engineer the challenge-response protocol, and write its own client.

  thought about a client certificate

It won't work. Attackers can extract the certificate and misuse it, like the secret.

You can obfuscate the code, add certificates, add secret data, checksums, and any client-side measure, they will not prevent a dedicated attacker from writing its own client if he has enough incentive.


Can I determine a private key given the encrypted data and corresponding cleartext?

If the key can be recovered from knowing both a plaintext and the corresponding ciphertext, then this is called a known plaintext attack; an extension is the chosen plaintext attack where the attacker not only knows the plaintext, but gets to choose it. If a cryptographic algorithm is subject to CPA, then it is considered weak and broken. Thus, a secure encryption algorithm MUST resist CPA (and therefore KPA too).

Note that with asymmetric encryption (RSA), since the public key is public, everybody can create millions of plaintext/ciphertext pairs. This illustrates that an asymmetric encryption algorithm could never have been considered secure if it was broken through CPA. Conversely, it was long assumed that with symmetric encryption, the CPA model was not scary, because the attacker cannot encrypt data of his own without knowing the key; practice proved that theory to be wrong (in the case of HTTPS, evil Javascript or even plain HTML can make your browser issue requests with contents at least partially chosen by the attacker).


My boss installs software using domain admin. Should I show that this is bad?

Using domain admin in the current days is like totally ignoring the network security and opening up the gates to the attackers! With tons of security breaches being announced everyday, Active Directory security in an enterprise plays a key role.

Below links detail the common mistakes of Active Directory deployments and the attacks because of the malpractices!

https://blog.netwrix.com/2017/11/22/active-directory-management-top-7-common-mistakes/

https://www.peerlyst.com/posts/taking-windows-domain-lateral-movement-to-the-next-level-mimikatz-less-instant-lateral-movement-claus-cramon

Below link is an exhaustive list on various security considerations for Active Directory deployments!

https://activedirectorypro.com/active-directory-security-best-practices/

I agree that there are members of senior management who doesn't bother about security, but it's the matter of survival in the digital era. With one small loophole in your network, you might end up as a victim with irreparable damage.

Cheers!


No-name Android app that can't be uninstalled

When in doubt, treat as compromised until proven different.

Steps you should take right now are:

Disable all permissions of that App under Settings -> App-Permissions (or similar)
Remove the App from the list of Device Administration Applications.
Change all passwords, treat each account as compromised. (Especially email)
Back up as much of your personal data as possible, possibly prepare for a reflash.
Disable all network connections on your phone, maybe even shut it down. I'm very sorry to be devils advocate, but this is best practice in security. Sadly, your phone is the center of your digital identity.


Is it safe for web application to receive and parse emails?

There is no specific problem with email. Processing any kind of external (and thus probably attacker controlled) content  has its risk and not only in the server. For example displaying the email within a web application can result in cross-site scripting, CSRF etc, similar to any other content displayed in the browser.


The vulnerabilities in this is really similar to facial recoginition, iris scans, and finger prints. In most cases they're easy enough to obtain and use, at least you need to buy wood glue for fingerprints. This just adds another layer of complexity. Johnny's comment is totally accurate. Do not rely on this as your only password.


Average time before a malware gets detected in the world

Statistics of this kind would be very difficult to gather unless there was clear and verifiable evidence of a creation date within the sample itself. That is unlikely for a variety of reasons, such as the fact that the vast majority of malware is a minor variation of a similar group or family. The only other way I can think of to "start the clock" would be to have a backdoor into the creation process of the malware, which for operational security purposes is not available.

If you absolutely need these statistics then my advice would be to see if you can buy them from your local mom and pop exploit development shop, assuming they keep track of when their code is first detected by an anti-malware engine.


You can use a Poisson distribution related to the number of events and incidents, as seen in Chapter 9, Measuring Security Cost and Value, as part of the book, IT Security Metrics: A Practical Framework for Measuring Security & Protecting Data.

The book also mentions in that chapter how to focus a WBS for hiring and project purposes. Another more-strategic method is Hoshin Kanri.

Highly suggest that you also lever the NIST Special Publication 800-181, the NICE Cybersecurity Workforce Framework (NCWF), to map out roles to knowledge, skills, and abilities for standard operating procedures. A nice interface to those roles can be found here -- http://www.cyberindustry.org/workrole/


Why is a public key called a key - isn't it a lock?

I'm not sure what locks you have experience with, but deadbolt locks are commonly used to lock from the outside.  Thus "Lock something in".

In this case, the analogy is that a "key" is something variable, and the "lock" is the algorithm.  The lock remains the same, while the key can be changed.  In public key cryptography the key used to lock is different from the key used to unlock.


How does a Distributed Denial Of Service Attack work

One possible way (UDP-Flood/Reflection/Amplification-Attack):

the attacker might use the zombies to invoke amplification/reflection-attacks like the ones performed some days ago link1 /  link2; the attack was (probably) an NTP reflection attack

In other words:

you have 20.000 bots
you have a list of 100 vulnerable NTP-servers with an 100 mbit/s - uplink
you are able to flood any target with (theoretical) 10 GB/s UDP - traffic
the victim is attacked from the NTP-servers, who received spoofed requests from the bots

the same applies for DNS-amplification-attacks or any other UDP-based floods

picture taken from Secureworks-Blog DNS Amplification Variation Used in Recent DDoS Attacks


From the wireshark perspective, one approach might be to look through the capture for ascii strings (using Follow TCP stream) and then search your hard drive for the same string.  If you can find something suitably unique, that might lead you to the downloaded data.

The pair of ports you descibe sounds like a standard web site download (the high port just being randomly assigned to receive the data)

Do you have any automated updating facilities turned on (OS/browser etc)?  One potential source of a largish unknown download would be software updating itself.

As you're running externally facing services from the box there is the chance that you've been compromised and that download was someone putting tools onto your system.  If that's the case you should do a thorough search of the server (some good information here)


Allow a PA to see a director's emails, but keep some emails private

I have done this in the past by:

Renaming "Director A" to "Director A (Private)"
Creating a Distribution Group called "Director A" that contains "Director A (Private)" and "PA A"
giving the PA delegate permissions so he can access the "Director A (Private)" calendar and to send mail on behalf of the "Director A" group, but not permission to access the "Director A (Private)" mailbox.

With this arrangement, when people send a mail to Director A, her PA is copied silently; when Director B sends a mail to Director A (Private) the PA doesn't see it.

The key difference between this and Rory's scheme is that the Directors do not need to have two inboxes, which makes things easier for them.

The main problem with this is that if Director A sends Fred a mail and Fred replies, then the PA isn't copied on the reply.


Your question lacks a lot of details, but in short if you read it correctly the domain expiration date is managed by a registry, for the given TLD, and to make it deliver a spoof element of data means someone found a way to crack it and alter some data in store or in transit, in some way.

While nothing is 100% impossible nowadays, the above seems not the most probable cause as there is many others ones. For example, many people are not aware where to go to retrieve authoritative data, and will use any thirs party website to do a whois query, which could return any kind of garbage as it would not be authoritative in any way.

There is only one authoritative and relevant database for this data, it is the registry one. It is certainly online in some way but can not be queried directly by the public (registrars do have a more close access to it through registration protocol such as EPP). It can be queried using the whois protocol, with a whois client, when you query directly the registry whois server. There is quite always a web version of it, but, again, you need to visit the registry whois website, not any third party.


That snippet in itself is not really a security check, it just checks that a value exists before using it (good practice, but not security related). The meat of your code will be in:

from mysql table where id = $_SESSION['id'];

And it all depends on how the data got to $_SESSION['id']. Either before inserting it there or before using it, you need to do the proper security checks, based on what are you going to use the value for. In your case, check for SQL injection AND you are better off using parametrised queries.

If your SQL actually looks a bit like what you wrote, that is, a concatenation of strings with the $_SESSION['id'] unqouted as a numeric value, then, yes, this is VERY vulnerable.


How do I protect the Azure Client ID and Client Secret in HashiCorp Vaults with AKV Auto-Unseal?

Reading your post, I think I understand your ask. You've already taken a great step of securing your credentials within a vault, but now you're concerned that the API credentials that allow you to secure your vault may be at risk since they are stored in clear text within a configuration file. The reality is that you will never likely get a solution that really eliminates some single point of failure that needs to be protected. The best you can do in situations like this is make it difficult for the attacker and go from there.

So the vulnerability that you are trying to manage assumes the following.

Your attacker has direct access to your file system
Your attacker has credentials to change file permissions
Your attacker is smart enough to know about Hashi Vault
Your attacker wants your credentials

The first assumption is probably the first major flag that you should notice in a secure environment. If someone is accessing your server files, that's a pretty major issue that needs to be looked at. There are also many ways you can control what people see through CHMOD, CHROOT, etc.

Now, the second assumption takes the first and says they not only have access to the server, but they have root/sudo priveleges. This is a major step of compromise and it means any native tools you could build into the server can be overwritten or reverse engineered. At this point you can't remediate the vulnerability because you've really lost the keys to your house already.

Steps three and four, once assumption two are complete are fairly straight forward. They can start to write application and API calls to glean credentials and harvest what they need. But, what's more likely is they'll go after any data they can fetch and then move onto their next target.

So, is it a potential vulnerability. Yes. Is it the highest priority vulnerability? No. Configure the best you can to the community best practices and keep your system safe from attackers and you should be golden. This is a last defense type vulnerability that's more like sending one or two guys in front of the hordes of Mordor and not having the hope of Frodo and Sam coming to save the day. It's pretty dismal.


CRL over HTTPS: is it really a bad practice?

I generally agree with Steffen Ulrich, I just want to add few cents, since OP references my own answer which I consider proper and valid.

However OSCP responses are also signed by a revocable entity

it's not a revocable entity. OCSP Signing certificates include id-pkix-ocsp-nocheck certificate extension that instructs clients to not check this particular certificate for revocation. Often, OCSP signing certificates don't include CDP (CRL Distribution Points) or AIA (OCSP access method) extensions in certificate. This trick removes egg and chicken problem for OCSP signing certificate.

CRLs are signed, but they still don't provide replay protection within the period of validity of the CRL itself.

that's correct. But this problem isn't solved within current X.509 profile. There are no means to provide immediate revocation response (i.e. immediately detect if particular certificate is revoked). Revocation infrastructure heavily relies on caching and even stappled OCSP response may not be very up-to-date, there may be newer responses, but server hasn't obtained it yet and use cached OCSP response to staple in TLS. As Steffen said, the only way to improve this experience is to use short-lived CRLs/OCSP responses and use clients that support CDP polling to detect if there is newer CRL than the one stored in local cache on a client.

I read also that certain implementations simply refuse to retrieve CRLs over HTTPS

Microsoft CryptoAPI behaves exactly this way in terms of CDP extension. It won't even try to connect to an URL with HTTPS scheme. It will fail the URL if server requests TLS negotiation. Don't know about other crypto frameworks, so this statement may not be applicable to other tools.
As a bottom line: I still don't see much useful reasons to implement CDP over HTTPS. CRLs is a publically distributable content -- no reason for content privacy. It is digitally signed -- no reason for extra signing. The fact that MiTM can modify CRL content over plain HTTP to purposely invalidate CRL signature isn't mitigated by TLS. MiTM can arbitrarily tamper TLS traffic to force client to reject tampered data. Same effect in both cases: denial of service and TLS doesn't solve this problem.
What can be reasonable -- to hide your activity history from men on a wire (e.g. your ISP), but yet questionable.


It depends how much verification you want. You can verify that the ID number entered matches the details supplied (assuming that whatever nation the ID card belongs to provides some sort of API to do this - lots of countries don't even have standard ID cards though), but all that proves is that the person entering the data knows both the card number and the details that are associated with it in the national store. If I stole your wallet, I can probably make a pretty good guess at that link - bound to be something (driver's licence, passport, etc.) with your full name and enough of your address to be able to get the rest from online services in there.

You can't verify that a specific person entered the details, nor that (with some exclusions, perhaps vehicles, buildings, and land) they own the thing they are offering for sale.

If your marketplace is for relatively low value items, verifying email addresses might be enough. For more expensive items, you might want to look at verifying bank account details - look at sites like Paypal for how this works. For high value items (houses, for example), you'd probably want some manual verification steps in the process - having a copy of identification documents made by a solicitor or similar. Depending on the country, there might be legal requirements for specific types of goods - cars might need to be recorded in specific ways and registration documents provided to a central database, say.

In general though, for a purely online process, all you can state is that someone who knew some details about a person entered them.


Difference between virtual and full patching of vulnerabilities?

Virtual patching tries to block the attack vectors, i.e. using some IDS, firewall or similar. But the vulnerability itself is still unfixed and if someone finds a new attack vector which bypasses current blocks the vulnerability can still be exploited.
Full patching instead fixes the vulnerability itself so it cannot be longer exploited by any attacker vector.

See also OWASP: Virtual Patching Best Practices.


Is Apple's push notification service implementation vulnerable to a MitM attack

I don't have too much time now and haven't verified this thoroughly, so this is only what I remember from looking into this a few months ago.

With OS X 10.9 and iOS 7, Apple introduced some sort of certificate pinning for the push service, i.e. not allowing any CA the system knows to sign their push server certificate, but only a specific CA. This certificate pinning was a bit strange as it had some sort of expiration date of January 1st 2014, but I didn't look too much into what exactly that means and I don't know whether the latest versions of OS X and iOS still include this.

  Unrecognized leaf certificate

So from my current understanding, this message doesn't mean apsd can't verify the certificate at all, but might mean the certificate pinning couldn't verify it (which would mean certificate pinning is currently optional, which in turn might have to do with the expiration date).

You might not have to worry about this directly, as the normal SSL certificate validation still works (as your test confirms). On the other hand I'd love to know why certificate pinning apparently doesn't work and what the expiration date means.

UPDATE: Here's some more information on why the log message is shown.

You can display the server certificate using openssl (same certificate seems to be served on ports 443 and 5223):

openssl s_client -prexit -connect 1-courier.push.apple.com:5223  2>/dev/null | openssl x509 -noout -text |grep -E '(Subject.*CN|Serial)'

As of 2014-05-10, this shows the following information:

Serial Number: 1277288244 (0x4c21df34)
Subject: C=US, ST=California, L=Cupertino, O=Apple Inc., CN=courier.push.apple.com

The apsd binary contains several X.509 certificates used for certificate pinning. I wrote a script to find certificates in a binary. Here's an excerpt when running it on apsd:

+ 469280 Found cert with CN "courier.sandbox.push.apple.com" and serial "1277027356"
+ 470416 Found cert with CN "courier.push.apple.com" and serial "1276925395"
+ 471584 Found cert with CN "Entrust.net Certification Authority (2048)" and serial "946059622"
[skipping some code signing certificates]

As you can see, the pinned certificate for courier.push.apple.com has a different serial number than the one served by Apple's push server. So both are different certificates and apparently this is the reason for the Unrecognized leaf certificate log message you see. As apsd still connects to the server, this means apsd does not require a pinned leaf certificate to match.

Another thing you can see is the third certificate, a CA certificate. Last year, when trying to make apsd connect to pushproxy, I had to replace the CA certificate to make apsd trust pushproxy. This means, while not checking the leaf certificate, apsd might only allow certificates from a certain root CA. I didn't verify this recently.

For checking this thoroughly, besides checking whether CA certificate pinning for the SSL connection is still effective, one would have to check another thing.
Before connecting to the push server, apsd downloads a 'configuration bag'. This bag is downloaded via HTTP, but signed. The bag contains the hostname apsd then tries to connect to. This is a way I'm using for pushproxy to redirect apsd to another host. You can find more information about the bag in the pushproxy README and a script to generate such a bag.


How do I stabilize a reverse shell in when the attack box is using powershell?

it's a very fragile connection. Ctrl + C will just drop the connection, tab doesn't auto complete, and the up and down arrows don't give me history.

It's not fragile. When you type Ctrl+C, the shell sends a SIGINT to the running process, which happens to be nc. This causes the process to terminate, breaking the connection. Tab doesn't autocomplete and arrows don't provide history because you aren't using a pty.

ctrl + z just locks up Powershell so that's about as far as I get.

Once you run that Python command to set up a pty, you can use keys to view history. However, on Windows, Ctrl+Z is EOF (equivalent to Ctrl+D on Linux). On Linux, Ctrl+Z will cause SIGSTOP to be sent to the running process, and it will be detached from the terminal. Because you are running Powershell, when you type Ctrl+Z, it is interpreted by Windows.


Why is the victim a server instead of a client?

This is all about the roles of everyone involved. Whether you are browsing a website, or buying a muffin from that cafe you know, the result is the same.

The server isn't the more powerful device, it's the one "serving" requests. The client is just that, the one that makes the requests that need to be served. You are the client when you request a muffin, or a website, or in this case remote access.

As a client you ask "move the mouse here", "open this for me", and "what do you see right now?". Then the server serves you by sending what you asked for. This is the relationship in all RAT applications.


Is it safe to recycle unshredded credit card receipts?

Most credit card receipts will contain your name and the last 4 digits of your card number.

I can think of several companies that either currently verify by last 4 digits or have in the past verified by last 4 digits. These are companies such as Apple, Godaddy, Paypal, etc...

So while the chances are low, it's still possible that someone could perform some degree of identity theft with this information.


To start with, if you can whitelist instead of blacklisting you can save a lot of efforts.

You can get a list from ModSecurity,  it is not simple to parse on your own but this is probably the most comprehensive you will get publicly.


Online challenge: Are there any known attack vectors given the following TLS setup?

One endpoint accepts a CSR and a private key

end of story. Client shall never expose their private key to anyone. Private key is known only to its owner.

  returns a certificate signed by the server's SSL certificate

only CA certificates are allowed to sign other certificates. SSL and other client-type certificates are not allowed to sign other certificates. CA and end-entity certificates are distingushed by Basic Constraints certificate extension. If isCA attribute is set to True, the certificate is CA certificate and can be used to sign other certificates, otherwise it is end-entity certificate and cannot be used to sign other certificates.

  if, and only if, the CN specified in the CSR is not "administrator"

there must be additional client authentication mechanism to determine if particular requester is authorized to get signed certificates from your CA (of course, if you have CA). Otherwise, any user can submit request on behalf of other users (non-administrators) and impersonate them. Ultimately, you need to authenticate and authorize every requester and sign certificate only when CSR contains names allowed for authenticated requester. Otherwise, CSR must be rejected.

  The other endpoint implements TLS 1.2 and asks for a client certificate that has the 'Distinguished Name` set to the server's organization name

this sentence is a bit unclear. What's the point of this requirement? If you want to allow client certificates signed by your CAs, it is better to use a CA whitelist in client certificate validation logic. That is, client certificate is accepted only when it is issued by an explicitly approved CA.


Passport.js out of the box is safe as your implementation of it to protect routes from unauthorized access. For example if you forget to apply the middleware to certain routes they would not be protected, if you make a mistake in configuring the authentication strategy you may open up your application to an attack. It is important that you heavily test you code for potential security issues as well as have code review from your co-workers to avoid your own personal bias.


Should the "Users" group be removed from Windows Servers "Allow log on locally" Security GPO setting?

I believe you've answered your question yourself correctly. Users and Guest accounts should not have the "Allow log on locally" rights on servers, only Administrators (and Backup Operators if necessary).

Here is a MS KBA in which security countermeasures are described:

https://technet.microsoft.com/en-us/library/dn221980.aspx

Quote:

  "For domain controllers, assign the Allow log on locally user right
  only to the Administrators group. For other server roles, you may
  choose to add Backup Operators in addition to Administrators. For
  end-user computers, you should also assign this right to the Users
  group.

  Alternatively, you can assign groups such as Account Operators, Server
  Operators, and Guests to the Deny log on locally user right."


Actually, daemons on OS X are equivalent to what is called daemons on Linux too. Both systems share a Unix ancestry. OS X is derived from FreeBSD. If you want to understand how security works on OS X, some Unix experience is advised. Sections 4 and 14 of the FreeBSD handbook would be relevant.

On a general basis, you should mind services (or daemons or whatever way you wish to name them) which offer an external entry point. The netstat -an command will show you what ports currently correspond to some server code, but those which are bound to 127.0.0.1 (aka "localhost") are not actually reachable from the outside -- so they are "safe".

OS X has the reputation of being "safer than other OS" because Apple invested a lot in a communications campaign which repeated that idea ad nauseam, until it stuck. One must admit that when it comes to Public Relations, the people at Apple are really skilled.


VM's are an abstraction we refer to for convenience. The underlying reality is that it's all code running on the host. You can protect a non running VM file with encryption, but a running VM client is running on the host, with host memory and host CPU. The host has access to everything.


does Avast SafeZone actually make a difference?

Yes, this is a well established technique for secure access to online banking and such.

The idea is to build a brand new machine from scratch every time you want to log onto your bank, and wiping it afterwards. Because the machine is only on for a few brief moments at a time, and because you do nothing with it apart from visiting your bank, it becomes very hard for spyware or other malicious software to infect it.

Obviously building a machine from bare metal every time is a pain, so to make this a practical technique you either use a VM, using a fresh copy of the disk image every time you use it, which is the approach SafeZone takes or a LiveCD.

It's a good technique, but if you want to switch to a different vendor, you still can, and implement this technique yourself. The easiest way is a LiveCD; a VM is very slightly harder to set up but easier to use. Both are available for free, for example you can grab a Ubuntu LiveCD from http://www.ubuntu.com/download/desktop or a copy of VMPlayer from http://www.vmware.com/products/player/

I suggest above that you use a fresh copy of the disk image with the VM; alternatively you can use the same image each time. This is slightly less secure in theory, but still fine for regular use, and makes it simpler. SafeZone defaults to this approach it appears, with a button to push if you do want to throw away a used image.
(hat tip to @polynomial's comment below for this)

Lastly, whether you use VM or LiveCD, one point that people sometimes miss is that you should regularly make sure that you have updated them with the latest security patches.


How to determine if mail was encrypted during transport using the header information?

Does the occurrence of ESMTPS in the first example mean that TLS was used for transport encryption?

Yes, but only if you believe the MTA that inserted that header and every MTA that touched the message subsequently. Any of those MTAs could write that information into the header even if it isn't true.

  Does the occurrence of ESMTP in the second example mean that the mail was transferred unencrypted between the two servers?

No, here's a counterexample:

Received: from XXX (XXXX [IPv6:XXX])
    by XXX (XXversionXX) with ESMTP id XXXX
    (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
    for <XXXmy-addressXXX>; Tue, 23 Jun 2015 10:24:53 +0900

That mailer appears to have chosen to include information about the connection crypto in parentheses and did not write ESMTPS. So it appears there are definitely multiple ways of indicating this information in the header and you'd have to recognize them all. But once again, you cannot trust any of it anyway.


Is there an XSS exploit to overcome stringification of all user input?

To avoid many attacks, you should pay attention to what type of content you're manipulating. What looks like text is not necessarily text. This applies both for SQL (SQL Injection) and HTML (XSS).

The string abc is written abc as text. It is also written abc as HTML. So you may think that if you have text to display, you can just concatenate it with the rest of your HTML. But no, you can't.

The issue is that some characters have a special meaning in HTML. The biggest issue is <, but & is also a problem, and you want to avoid a few others for various reasons, including > and quotes, if what you are writing is an HTML attribute.

So, what you need to do is convert your text to HTML before you insert it into HTML: text is not HTML, and HTML is not text.

In some languages you have standard functions to do this, such as PHP's htmlspecialchars which you should use on every single piece of text you insert into HTML.

In Javascript, there's no standard function for this, so you have two alternatives:

You don't write HTML. You shouldn't anyway. You should create DOM elements, then set attributes on them, or set the text contents of them. If you use jQuery, that means you shouldn't write:

// XXX DON'T DO THIS! EVER!
$(thing).append($(''+string+''));

You should instead write:

$(thing).append($('').text(string));

You shouldn't use .html() either.

Likewise, don't do this:

// XXX DON'T DO THIS
$(thing).append($('"));

Do this instead:

$(thing).append($('').attr('src', url));

Or, if you really want to write HTML, then you need to convert all your text to HTML to do that. This means at the very least replacing: < with &lt; and & with &amp;, but you also want to replace > with &gt and " with &quot; and ' with &#39; if that will end up in an attribute (easier to always do it). A regex replacement will do.

JSON.stringify will not help you here. JSON.stringify will not convert text to HTML, it will convert text to JSON. You want to use (actually, you need to use it) if you want to insert text into Javascript (though this would more likely happen server-side). But it doesn't protect you against XSS.


Database compromised (SQL-injection): how to handle the situaton, after the fact?

1. The hole has been plugged, what technical steps should be taken now (other than rotating the MySQL user credentials, which we have already done)?

Audit the website. Preferably by someone outside the company if you have the budget. The search term you're looking for is "pentest". Furthermore, if your application displays any data stored in the database directly onto the website, check if the attacker opportunistically put some stored XSS in there. (Javascript to steal cleartext credentials for instance)

2. Since we have the log files with all query attempts, it should be possible to figure out exactly what tables have been dumped. What is a viable tool for pulling this information from a combined 1 GB of webserver access and error log files?

I'm not aware of such tool, sorry. You could always try and do it manually. Try and use any kind of scripting language (bash and command prompt will do for this) to recreate the executed queries from the log files. From there you can easily figure out what tables were accessed, it would be a lot of work to get more details in this matter though.

If you do this, look for insert and update statements, to see if he modified or added data as well.

3. What are the common malicious uses of stolen data such as this? Phishing attacks aimed at the webshop's customers?

It can be used for a few things. I'm assuming the list also contains email adresses? (webshops often do)

The attacker could try and use your data to compromise other accounts on other services. he could:

try and crack the passwords, and use these on other websites. Were the passwords salted? If not, he can try to use rainbow tables.
Use the information of your website to try and recover accounts on other websites without cracking the password. By using recovery questions.
Use the email addresses(if you stored them) for spam purposes. He can also just sell the email list.
phishing like you mentioned yourself


How safe is it to use shared SPF record domains?

Can my competitor bypass this security meassure by sending e-mails from competitor.com using my domain secret.com?

Yes, competitor can bypass this, but not easily. Lets say that SPF is

"v=spf1 include:spf.mandrillapp.com ~all"

This means that I allow server spf.mandrillapp.com to send emails for my domain, while all other will SoftFail (that is the ~all).

So back to the question, competitor would have to use the spf.mandrillapp.com to send emails using your domain. This is standing on one big BUT: but the competitor would have to have access to this server. So your mail is secure until your mail hoster does not give access to send mails as your domain form this server to competitor.

  I assume that this way the SPF records check, will show that the domain competitor.com is allowed to send mails from my secret.com domain right?

No! This gives permisson to spf.mandrillapp.com, and others will SoftFail. You can read more about SPF records on Wikipedia.

  Or can the use of such shared SPF domains like above cause other risks?

Your mail is secure until your mail hoster does not give access to send mails as your domain form this server to competitor.


Is Android's Password Screen Lock Enough Data Theft Protection?

No.  The pattern/PIN screen lock is not sufficient to protect the data against sophisticated attackers.  However, it might be good enough in practice for most users, if the data is not super high-value.
There are two cases, depending upon whether you enable encryption of internal storage or not.
If you do not enable encryption. In this case, the data is stored on your phone's internal storage in cleartext.  In principle, a sufficiently sophisticated attacker, if he has access to your phone, can likely disassemble the phone, pull out the flash chips, and read off the data.  However, this requires more sophistication than an ordinary thief is likely to have.  It's not as simple as just plugging in a USB cable.
So, if you're primarily concerned with garden-variety thiefs, a lock pattern or PIN might be sufficient, if the lock pattern or PIN is long and strong enough.  Some caution is required, because your fingers are greasy and leave smears on the phone, which are visible later.  The thief might be able to figure out your lock pattern or PIN from these smudges.  See, e.g., the following research paper:

Adam J. Aviv, Katherine Gibson, Evan Mossop, Matt Blaze, and Jonathan M. Smith, Smudge Attacks on Smartphone Touch Screens, WOOT 2010.

I've summarized the findings of this paper elsewhere, but the short version is that smudges are a serious threat to security, and it's hard to say for sure that you will be safe.
If you do enable encryption.  If you enable encryption, then all data on internal storage is encrypted using an encryption key derived from your lock pattern or PIN.  In principle, you might imagine this would provide strong security, but in practice, it has several serious shortcomings:

Low entropy. There's just not enough entropy in a pattern or PIN to provide a strong encryption key.  Others have calculated that there is a maximum of about 400,000 possible Android dot-patterns.  That's only 19 bits of entropy, which is definitely not sufficient for an encryption key.  (This is probably an overestimate, because not all patterns are equally likely; the short ones are probably far more likely.  This makes the actual situation even worse than these numbers would indicate.)  The number of possible PINs is comparable, or even lower, depending upon the length of your PIN.
If a sophisticated attacker gains physical access to your phone, he can likely disassemble it, extract the flash chips, and read off the encrypted data.  Then, he may be able to mount a simple brute-force search that tries all 400,000 possible lock patterns, deriving a candidate decryption key from each, and seeing which one works.  A 19-bit cryptographic key is not sufficient security to prevent this kind of brute-force search.  So I think it would be prudent to assume that if the attacker has enough sophistication to disassemble the phone and read the flash chips, he may be able to get access to your data.

Smudge problems. In this scenario, the smudge attack is just as bad.  If the thief can recover your unlock pattern or PIN using the smudges on your phone, then obviously the thief can gain access to all your data.  See above for discussion of the smudge attack; the short version is that it's hard to say for sure that you will be safe.

Bottom line. If you just want to protect yourself from a thief who grabs your phone and runs, then an unlock pattern or PIN may be sufficient.  Realistically, such a thief probably just wants a free phone of their own; they probably don't care about your data very much, or won't expend much effort to try to get to it.  So, as long as there is no trivial way for them to gain access to your data, I'm guessing the average thief won't bother; they'll just reset your phone to factory defaults and then start using it.
On the other hand, if you have reason to think that you might be targeted by someone with an interest in the data on your phone, I don't think any of these methods are enough to provide strong protection.  Turning on encryption helps a bit, but probably does not provide strong protection.
If you want to protect yourself from the smudge attack, you could get in the habit of wiping off the screen of your phone (this is far from perfect, but it may make the smudge attack harder or successful less often).
For more reading, see Are the iPhone “connect the dots” passwords secure?.
USB debugging. What about USB debugging, mentioned by others?  Well, sure, if you enable USB debugging on your phone, then a thief who knows about this can just hook up a USB cable and dump your data.  But very few end-users will ever enable USB debugging (and what fraction of ordinary street thieves are going to know about this, or bother trying it?), so this is probably not relevant to most Android users.


Password cracking speeds according to Hashcat

Yes.  The Dev.#* they list is Hashcat's way of showing the combined cracking speed of all GPU devices.  Normally the Hashcat benchmark output would look like this:

Hashtype: sha512crypt, SHA512(Unix)

Speed.Dev.#1.:   147.5 kH/s (103.12ms)
Speed.Dev.#2.:   138.1 kH/s (102.84ms)
Speed.Dev.#3.:   148.0 kH/s (102.83ms)
Speed.Dev.#4.:   148.3 kH/s (102.57ms)
Speed.Dev.#*.:   581.9 kH/s

Which better shows the individual device speeds as well as the combined speed.

You're also correct that kH/s means the associated number represents thousands of hashes per second, with MH/s representing millions, GH/s representing billions, etc.  And yes, the H/s measures how many different password guess to hash conversions are made every second.  So your H/S will be slower for an algorithm like sha512crypt, compared to MD5, because it's measuring the time it takes to complete the entire hash conversion and not just one round/iteration.


What is an ITGC Audit?

ITGC stands for Information Technology General Controls.  While it sounds general, there's a backing standard and set of documentation that auditors use to maintain some consistency from the IIA (Institute of Internal Auditors).  Non-members of IIA can buy copies.

Some important points -

It's a standard, not just a willy-nilly set of what your 3rd party auditor thought would be good to check.
If you want to, you can buy a copy of the rules you're being compared against.  (I make no claim that you, or I, could understand those rules! But it's something...)

  I don't get the purpose of such an audit

That's a broad question.  Here's an analogy - I have to take my car down for a Safety & Emissions inspection every year.  They review a very limited number of aspects of my car (tailpipe emissions, turn and brake signals work, headlights aimed correctly, etc.) as a form of due diligence that my car is safe (for myself and others) to be driving on the road.

The purpose of an ITGC audit is to ensure that the car (computing resources) of your company is basically safe - not generating undue risk to your company.  If my car causes an accident because the headlights don't work, myself and others can get hurt.  If your company causes an accident because your databases don't work, then various people - employees, shareholders, customers - can get hurt.  The ITGC audit is the test to make sure your setup is correct enough so as not to be a danger to yourself and others.

  especially given the way it is conducted.

Also kind of broad.  Let's drill into the example you've provided and make some guesses.

  The kind of requests from the audit teams are: Can you give us a
  screen shot of the installation folder of xyz financial applications
  and what server(s) they are on?

Your company says to the auditor, "we run SAP ERP to manage our financials."  Being an auditor, they can't just take your word for it.  They need proof.

The audit world has been moving rather strongly over the last few years towards Proof.  SOX audits are much more rigid about getting a screenshot to provide evidence of something.  PCI 3 got much more explicit about the auditor needing to actually see evidence rather than just being told.  Both are shifting to require that the evidence collection be under the eyes of an auditor, to ensure no evidence tampering takes place.

Installation directories are the simplest form of proof that something is installed.  Screenshots are the cheapest, easiest form of proof to gather with any evidentiary integrity.

So they want to know that you've got financial software, what servers it's on, and have some sort of proof that that's true.

Later on in the audit, they're going to be asking you about disaster recovery.  And when they get there, they're going to say "Show me the your list of assets and their DR rating, e.g., what's most important to return to service after a disaster."  And they'll want to cross-check that the list of servers that you put your financial server on are all in the right tier.  It's a basic safety check - if your ERP web frontends are tier 1 recovery, but your ERP database backends are tier 3, then oops!  Your whole ERP solution is tier 3, which is probably not what you wanted.

  This is of no material significance to anything / anyone.

Well, I disagree.  I would rather know that my stock broker is using an enterprise-class database with redundancy and not hand-coded Berkeley DB files as a backend for my trading.  I can't go in and demand they tell me, of course, but if they've gone through a reputable audit, I can feel comfortable that somebody looked at their setup and decided it was sane.

  Not to mention, I can change this information from day to day given
  the virtualized architecture of our company.

You could.  You could do it deceptively and maliciously to mislead your auditors - which is they they now ask for screenshots and shoulder surfs, to make it more difficult.  You could also do it legitimately in response to business need, but most likely, business need is not going to be to switch to something that wouldn't pass an audit the second the auditors leave the building.

  In fact, it's likely to change multiple times before next year's
  audit.

Audits are point-in-time only.  However, the expectation is that

You won't shuffle things in time for the purpose of fooling an audit, and
If you're doing things in an audit-acceptable manner today, then hopefully you are doing your job correctly enough that you'll do it in an audit-acceptable way tomorrow when you have to change it.

  I must be failing to grasp some significant relevance? What is the
  purpose of one of these audits? Who / what is it meant to protect?
  What is it meant to prove?

I think you're missing the following things about audits.

"Audits" aren't called "Enforcements" for a reason.  They're looking and making notes, and they'll make recommendations, but they're not going to touch your stuff, and they're not going to whip out the thumbscrews to force your cooperation.
Audits presume reasonable levels of cooperation.  Yes, they realize you could lie and cheat, and they do things (like screenshots) designed to make that harder.  But at the most basic level, IT audits are not adversarial.
ITGC Audits protect everybody.  The make sure you're doing things properly enough not to be a meltdown waiting to happen - because when companies melt down, employees lose their jobs, shareholders lose their money, and consumers are impacted.  (Other types of audits may be more limited in their protective focus - an IRS audit, for example, is focused on protecting the government and the taxpayer, and the company being audited is not being protected).
Audits prove nothing except that the Audit was performed (and only up until the point in time the audit was completed).  Now, due to standardization, that means a lot more than it used to.  The only thing the audit proves is that someone came in, asked questions, collected answers and evidence, and applied an organized set of judgments to that data, resulting in recommendations.  So while they prove nothing, they do have some beneficial side effects.

ITGC audits measure what you're doing against they way a set of auditors have decided things should be done, or should not be done, based on history, knowledge, and experience.  They can be enormous, imprecise, and focused on inane details all at the same time.  They can be helpful, or they can be a waste of your time.  Half of that is getting a good auditor - and the other half is how you work with your auditor.

Good luck!


Replacing < and > characters isn't enough in all cases. Sure, it will prevent any user to open a HTML tag, but that won't prevent him/her to inject HTML attributes in a HTML tag.

For example, let's take a parser which transforms [img=XXX] into , only replacing < and >.

A malicious user could enter [img=X" onerror="alert(1)] and the parser would return:

And the alert will prompt, meaning that a XSS attack is possible.


How long does the system encryption key stay in RAM

Disk encryption is about keeping data on disk encrypted at all times; writing back the decrypted files onto the disk would incur the risk of leaking that data (if the machine is stolen at that point) and would require re-encrypting it upon shutdown. Note that a typical mechanical hard disk reads and writes data at about 120 MB/s, so a mere 128 GB hard disk would take more than 15 minutes to be decrypted entirely, even assuming that the decryption process is faster than that and that the disk is the bottleneck. You certainly don't wait for 15 minutes when you boot your machine up.

All this implies that decryption occurs on-the-fly, when files are read. A consequence is that decryption occurs as long as the machine is up and running, so the decryption key MUST be somewhere in RAM, and stay there.

Similarly, if you modify some files and want to save them (so as to get the new files back after the next reboot), then the encryption key must necessarily be used.

However, there are (at least) two methods by which you could envision not to keep the key in RAM:

You could read and decrypt a complete filesystem into a RAM-based disk. There, decryption could be done once and then the key discarded. Of course, this limits the total filesystem size to what can fit in RAM, e.g. 1 or 2 gigabytes. Moreover, all writes will be discarded (conceptually, one could use asymmetric encryption to save modifications, to be incorporated into the encrypted filesystem upon next boot, but that's likely to be a significant design and development effort).
The TRESOR project aims at doing encryption and decryption by keeping the keys in the CPU registers, and not allowing these registers to be flushed to RAM. This is for defence against cold boot attacks, in which attackers can take a good view at the whole RAM contents but not at the CPU registers as they were prior to the attack. It has been noted that attackers that can do DMA can inject malicious code that extracts the keys from the registers, so the protection cannot be considered as complete in that case.

An important point to consider is that you use disk encryption to keep the confidentiality of your data -- but when you access your data, you still pull it into RAM in order to process it. For instance, if you look at the contents of some text document, then, when you look at it, the document data necessarily exists unencrypted in the viewer application space, and the graphic card memory as well. Protecting the encryption key is all fine, but if the attacker is assumed to be able to read your RAM then he may plunder the data directly. Therefore, concentrating on the whereabouts of the encryption key without addressing the larger picture of the data kind of misses the point. In most practical contexts, it does not make a lot of sense to worry about cold boot attacks retrieving the disk encryption key -- even with all the TRESORs in the world, cold boot attacks would still be almost as worrisome.


If you rely only on the hability to access to the declared email address, I think you should have eavesdropping detection methods.
For example, in your current flow, if an evil E accesses to the mailbox after the owner, E can still click the link and be authenticated.
Also, every NSA router (so every router ^^) between your API and the user's mail server can read the token if the email is not encrypted (which is not only under your control).
So a "burn after using" should be implemented for the token.
So if the token is automatically eavesdropped and used before the legitimate user, he will see that someone took the access (because the token will be burned and his access will be refused). And if the token is acceded after the legitimate user, it has no value anymore.
So the authentication token, after been used, must be different from the session token used to maintain access for the user.


is there a way to close 22 ssh port from public, ubuntu?

If you connect to the ssh server from only a known set of ip addresses, then it's a wise idea to restrict access to only allow incoming connections from these addresses.  By blocking incoming connections from all other address, this mitigates attacks that may exploit a potential zero-day vulnerability in ssh, or a configuration error.
You can do this in Ubuntu using ufw (uncomplicated firewall).  As root, do the following:
ufw allow from x.x.x.x to any port 22

(where x.x.x.x is the ip address that you want to allow incoming ssh connections from).
Then,
ufw enable

That should do it.  To be sure, run the following command:
ufw status verbose

This should produce:
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22                         ALLOW IN    x.x.x.x

Related:
Is starting an AWS instance with only ssh to port 22 significantly insecure?
Logging in to a VPS using ssh and ssh to another VPS using ssh. Does it improve the security of the second VPS?


question on hashing an aes-encrypted file

If you take a CBC-encrypted file and alter one bit (i.e. change a zero bit into a one, or vice versa), then, upon decryption, this will:

jumble more or less randomly the corresponding block in the plaintext data;
flip exactly one bit in the next block (i.e. 128 bits further);
change nothing else whatsoever. In particular, decryption won't "fail".

See the schema on the Wikipedia page for CBC to understand why this works that way.

What you are seeing is that when you use encryption (for confidentiality), you usually also want to have checked integrity, with a MAC algorithm such as HMAC. It so happens that properly combining encryption and a MAC is tricky. Your best bet would be to use an encryption format which already does things properly. If you must, for some reason, do your own encryption, then try to use an encryption mode which inherently includes a MAC, e.g. GCM or EAX. If for technical reasons (e.g. lack of available implementation) you must still use CBC, then add some HMAC with the following rules:

Hash your master key K (the one you "store securely") with SHA-256. Split the 256-bit result into two 128-bit halves, K1 and K2.
Use AES-128 in CBC mode, with K1 as key, to encrypt the data. Be sure to use a random IV, generated anew for each file, with a cryptographically secure PRNG.
Compute HMAC/SHA-256, with K2 as key, over the concatenation of the IV and the encrypted file.
Store the file in some format which will include the IV, the HMAC output, and the encryption result. Simple concatenation would work, since the IV and HMAC output have known fixed lengths (16 bytes for the IV, 32 bytes for HMAC/SHA-256).
When decrypting, verify the HMAC value first, and proceed with data decryption only if the HMAC value appears to be correct.

You may note that I advocate for AES-128, not AES-256. This is because a 256-bit encryption key is needless overkill and incurs a 40% speed penalty. If you still want a 256-bit encryption key, e.g. because you need to woo some clueless manager with how big your key is, then use SHA-512 to hash your master key K into a 512-bit output, which can be split into two 256-bit halves.

I also recommend HMAC/SHA-256, which should be "fast enough". A basic PC can do AES-128 and HMAC/SHA-256 combined at more than 60 megabytes per second. If you need more speed and you have a 64-bit platform, then HMAC/SHA-512 can give you an edge, but at the expense of making it harder for 32-bit systems. In any case, 100 Mbit/s network will top at about 11 megabytes per second, so encryption speed will probably not be an issue anyway.


Find the process that queries a malicious domain every 2 minutes

Whats the meaning of "Dnscache" in netstat result?

Its a legitimate client process used as a local store (cache) for DNS responses. All responses are kept for the duration of their TTL.

why it doesn't stop after ipconfig /flushdns

Not sure its suppose to stop/restart/etc. You can run the following command to see if flushdns worked.

ipconfig /flushdns && ipconfig /displaydns

Why client query that domain continuously but i don't have any traffic with the domain?

Dig into the DNS request/response. Perhaps the necessary information is included in that exchange (i.e. DNS data exfiltration).

How to find the root cause?

Take a closer look at the svchost instance. Once you have the PID replace 0000 in the following commands. Compare these results to a known good system.

The following command will list the services using the target svchost. This will greatly narrow things down.

tasklist /svc /FI "pid eq 0000"

The following command will show the loaded modules.

tasklist /m /FI "pid eq 0000"

You're on the right track using procmon. If you're certain that svchost is hosting malware, configure the procmon filter to only capture events for that PID. The resulting information should give you everything you need.

As @razvan-socol mentioned in the comments, use autoruns to identify how it starts up.

Ps: i checked the client with two different AV and it was clean, Just i know the client has visited a website that contain a js with that domain few days ago.

Its calling out every two minutes though right? And that's not normal for your environment right? With a two minute beacon, the malware doesn't appear to be taking steps to hide its activity. However you should consider taking the system offline for analysis.


Site use weak cipher and TLS older version

Can this issue be related to the Certification Authority that provides the certificate?

No, the Certificate Authority has nothing to do with the ciphers supported by the server. The server supports a cert of ciphers according to its capabilities and configuration.

Or this issue is related to the possibility of older browser usage?

Older browsers don't support newer ciphers. The question is, do you want to jeopardize the security of all your users just to support people who still run Internet Explorer 8, which has been End-of-Life since Mid-2018.
What to do now?

Remove Support for SSLv3, TLS 1.0 and TLS 1.1.
Configure TLS 1.2 to only support strong ciphers, which provide Forward Secrecy

SOGIS recommends only using the following ciphersuites (see Chapter 6.1):
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CCM
TLS_ECDHE_ECDSA_WITH_AES_128_CCM


How did FBI/DoJ retrieve the data stored on the encrypted iPhone?

[Update #2]

According to the Washington Post, sources familiar with the matter, have stated that the initially suspected collaboration with Cellebrite is not how the data from the encrypted iPhone was recovered. Instead an unknown security vulnerability was used (purchased) from "professional hackers" to prevent the phone from erasing its data and slowing down the passcode check. This would mean that the FBI probably brute-forced the passcode once those iPhone security measures had been deactivated.

https://www.washingtonpost.com/world/national-security/fbi-paid-professional-hackers-one-time-fee-to-crack-san-bernardino-iphone/2016/04/12/5397814a-00de-11e6-9d36-33d198ea26c5_story.html

@Gandalf brought to our attention that the DOJ has now confirmed they successfully accessed the iPhone 5C and can indeed access any iPhone 5C running iOS 9 this way: http://money.cnn.com/2016/03/28/news/companies/fbi-apple-iphone-case-cracked/index.html

There is a good article about the current known facts here:
http://www.bloomberg.com/news/articles/2016-03-28/u-s-drops-apple-case-after-successfully-accessing-iphone-data-imcj88xu

  The official declined to provide any details, such as what was on the
  phone, the identity of the third party or how the method worked. The
  official also declined to say whether the U.S. will give Apple details
  about the hacking method.

According to other news reports the FBI decided to go with a company that stated it could unlock the phone for them. Something that had been suggested to be possible for a while. They did not specify which company / third party is going to do this, but several articles suggest it's an Israeli Company, named "Cellebrite":

Original Report: http://www.ynetnews.com/articles/0,7340,L-4782246,00.html

http://www.theverge.com/2016/3/23/11290374/apple-iphone-fbi-encryption-crack-cellebrite
http://www.reuters.com/article/us-apple-encryption-cellebrite-idUSKCN0WP17J

The speculation is suggesting NAND mirroring to be used to gain access to the device memory and copy everything to another device, but at this point the exact how-to is not publicly known.

This article also found a recent contract reference between that company and the FBI: http://www.macrumors.com/2016/03/23/fbi-israeli-firm-cellebrite-to-unlock-iphone/

They also speculate about a microchip attack and brute-forcing the passcode once the data has been extracted from the device, but the company is likely going to remain very quiet about the exact "how-to" and so will the FBI for obvious reasons.

[Update #1]
The EFF has published a statement that suggests any used security vulnerability might be reported to Apple, if the FBI was to follow the guidelines that the EFF had previously acquired through a freedom-of-information lawsuit: https://www.eff.org/deeplinks/2016/03/fbi-breaks-iphone-and-we-have-some-questions


CSRF token unique per user session - Why?

The attack vector here is disclosure of the token. The defense is not so much concerned with specifically how that token is disclosed, but addresses any method in which an attacker might obtain that value. If an attacker can obtain the token, that opens the possibility they can craft a CSRF attack. Again, the specific method of attack itself isn't the concern here.

The purpose of changing the token is to limit the window of opportunity. You could have the CSRF token change once a month or have it change on every request. Changing it with every session is a good middle ground that avoids some of the complications of a token changing too fast yet still provides good limits of exposure. Ending a session is also a natural transition of state, so that also makes it a good place to change the CSRF token.

Limiting your overall exposure to CSRF can make changing the CSRF token with every session less important. Some ways to do that are:

Passing the token as HTTP header rather than a form value.
Properly using POST vs GET requests when updating data or initiating transactions.
Using the SameSite cookie attribute, the Secure attribute, and the __Host- or __Secure- cookie prefixes to help protect cookies from exposing information or being overwritten.
Using the Origin and Referer HTTP headers to verify that the request came from the expected location.
Providing additional interactive steps such as a confirmation page or even re-authentication for the most sensitive actions.

Deciding when to renew the CSRF token depends on your overall risk and general resistance to CSRF attacks. With a good defense-in-depth strategy you might be able to compromise on on how frequently you change that token.


How to generate a password dictionary for a specific use

It would be pretty easy to write a script that will generate every possible key according to those rules and dump them in a .dat file. If you want, I can whip one up for you in python and post it here, but I don't think that would actually solve your problem.

Taking a rough squint at the math, you have an alphabet of 37 characters (26 letters + 10 numbers + _), with lengths of up to 40, so that's at least 37^40 different keys to try. At40 bytes per key, you're looking at roughly 10^66 bytes of data to store this file. Note that a terabyte is 10^12 bytes, so you would need 10^54 1 TB hard drives just to store the file.

The only way this would finish in your lifetime is if you know something about how they generated the keys which allows you to cut down the list of possible keys by 99.999999...% For example if you know that they only used 8-digit keys, or the keys were all English dictionary words, etc.

Without a lot more information, I don't think you're going to get much traction with this approach. :-(

Update:

If the key is a computer-generated random password then you're sunk with this approach, but your comments indicate that there's some chance that a human typed it in, which means there's some chance that you'll stumble across it in a cracked passwords dictionary.

skullsecurity.org seems to be a good source of leaked password lists (and comes with a recommendation from this answer).

crackstation.net seems to host a giant 15 GiB password list, though I can't personally vouch for it.

Depending on how much that file is worth to your company, you could download some of those lists, rename them to .dat, dedicate some computers to the cause, start one copy of the decryptor per CPU core (each one working on a different password list). Check on them after a month and with luck, one of them will have spit out a decrypted file. It's unlikely to work, but if the file is valuable enough to you, it could be worth trying.


How CDN operator will decide content fo me if i am using google public DNS

Your question is not exactly very clear so I'll take a stab in the dark and try to interpret your question.

What DNS server you use has no bearing on your "location". That is entirely dependent on your public IP address. If you are using a home broadband, it is very likely that you will be using a public IP address shared with many other people through NAT.


rdp-sec-check is a Perl script to enumerate the different security settings of an remote desktop service

The following potential security issues are flagged if present:

The service supports Standard RDP Security.  This is known to be
vulnerable to an active Man in the Middle attack.
The service supports weak encryption (40-bit or 56-bit).
The service does not mandate Network Level Authentication (NLA).  NLA
can help to prevent certain types of Denial of Service attack.
The service supports FIPS encryption but doesn’t mandate it – may
only be interesting for jurisdictions where FIPS is required


Is it safe to use non-ASLR DLL in an enabled ASLR EXE

On Windows, an executable that is ASLR aware (compiled with /DYNAMICBASE) can load a library (DLL) that is not compatible with ASLR.
In this situation the DLL will not typically use ASLR, though newer versions of Windows are becoming stricter and enforcing ASLR even on some images that don’t opt-in, unless relocations have been stripped (for example by linking with /FIXED).
Doing this can weaken the protection provided by randomised memory, because there will now be an image at a predictable address. However, there must first be some form of vulnerability in the program. Simply loading a DLL is not a vulnerability alone.
For example: a common way for malicious RTF documents to bypass ASLR in Microsoft Word after initial exploitation was to craft a document that ensures  otkloadr.dll is loaded into memory, read more here.
There’s also a useful blog from Raymond Chen about the difference between relocation and ASLR and some facts about ASLR from FireEye.
Regarding DEP, or NX, there’s a useful quote from a different Raymond Chen blog on enabling NX and ASLR:

The NX setting is process-wide, and the process takes its NX state
from the /NXENABLED state of the executable, not from any DLLs. It’s
yet another one of the module flags that are meaningless for DLLs. So
mix it up in the DLLs all you want. Nobody will care, because the flag
is ignored for DLLs anyway.


Are foreign keys linking to a table with PHI considered PHI under HIPAA?

To answer your question according to the points:

1) In a pure sense, no.  PHI means identifiable patient information (e.g. a name, an address, a social security number, etc) combined with clinical data (e.g. a diagnosis, CPT code, test result etc).   A foreign key in and of itself is not PHI.

2) Not that I am aware of for HIPAA -- HIPAA is more of general guidelines than clear, distinct standards.

3) Yes!  If it makes you worried that the release of any particular data might cause problems for your company, your customers, or especially trigger HIPAA breach notifications: encrypt it!  With HIPAA, it's always best to err on the side of encryption.  If properly encrypted data is compromised, this does not trigger reporting requirements; which can be a life saver for a company -- especially a small one.


A good privacy policy or pursue encryption for private community?

The two are not mutually exclusive.  You can build a close, trusted community in addition to using cryptography to help support it.  Encryption would also help protect the information against an outside attacker.  You also don't have to have the clients themselves maintain the keys, that isn't very useable, but you can have encryption keys protected with their passwords that are managed by the server to simplify use of the site without sacrificing much in the way of security.


Guarding against XSS when setting Cookies based on URI?

It would seem like the solution is to provide the user with an intermediate page after they enter the cookie-setting URL.

On such page, simply provide a link back to itself.

Within nginx.conf, check for $http_referer in a location of such page; if it matches $request_uri, set the cookie; otherwise, serve the page with the link to itself, with Cache-Control: no-cache.

This solution relies on the idea that it is not possible to modify the HTTP Referer header (through JavaScript or otherwise) in requests performed by web browsers.

It would even be immune even if it was possible to access raw TCP sockets from JavaScript (raw sockets from web-browser's JavaScript are not possible for security reasons) and create your own custom requests, because even then such sockets would exist in a separate realm than the HTTP requests from the web-browser engine itself, and replies would not be treated as HTTP, and would be unable to set any cookies.


Are different top level domains somehow different security wise?

In the general case probably not, although I'd imagine that the authorities running each TLD will have varying levels of technical and operational security, so your domain may be safer with some than others.

One specific case to note however is the prospective .secure TLD whose goal is specifically to provide a secure environment both in terms of their security and the security of sites within the .secure TLD


Browser gives access to root directory through "/"

For many Linux browsers (I've tested Opera, Firefox, and Konqueror), this is normal: a bare / is an invalid URL (there's no protocol), and it gets interpreted as file:///: "display a directory listing of the root directory".  There's no security risk here: only you can display the contents of your computer's root directory using a file: URL, you cannot display the root directory of any other computer, and browser security policies keep Javascript from accessing it.

The file:/// URL (or its Windows equivalent, file://c|/) is often used in scareware scams: the scammer will display it in an iframe on their website and try to convince you that it represents some horrible security leak, which their software can patch.


How could I be sure that the network cable is safe to use?

I would try to use a cable analyzer for example the DSX-5000 from Fluke. This analyzer should be able to guarantee the continuity of each cable and its characteristics. That should be enough to detect the presence of an unwanted switch or any port mirroring device.

Maybe a simple continuity tester could be enough, but a more professional/expensive cable analyzer could give the cable length, propagation delay, and many other physical elements that could be changed even by a derivation on a line. The hard part would still be to correctly interpret the results, but any strong difference from the standard measures would be a hint that something weird could be there...


Reason for Subject name in an X.509 Certificate

Your question doesn't seem to be the reason for Subject Name, which is to identify the subject, but rather whether it works.

Gutmann writes colorfully and at some length on things that actually don't matter most of the time, although when they do it's very useful to know about them. Yes, the full X.500 naming scheme specified to be used in X.509 certificates in general is a monster. (Committee designs are traditionally depicted as camels, although in this case octopus seems appropriate.)

However, SSL/TLS certificates and particularly web server certificates -- which is the only kind most people encounter and the only specific case in your question -- avoid the issue by really using only the CommonName attribute in Subject(name) to contain a 'fully-qualified' domain (DNS) name aka FQDN, or possibly (but rarely) an IP address; or nowadays usually the SubjectAlternativeName extension to contain FQDN(s) and possibly IP address(es). Although in actual operation (especially at its current worldwide scale) DNS isn't perfect either, most people can understand it easily enough, and certainly the domainname in an http:// or https:// URL is easy enough to see.

A legitimate CA should issue a certificate for a given domainname only to the 'owner' of that domain, although exactly what counts as ownership varies a little. You can visit each CA site and look at their application/validation rules and processes, or see CA/Browser Forum under Baseline Requirements which sets the (minimum) standards for CAs to be included in the truststores of most browsers and OSes (at least on consumer devices), and thus the ones most users end up trusting.

Thus, if the CAs do their job and attacker M can't either trick or force a trusted CA into wrongly issuing him a cert for domain D -- which has happened in a small number of cases, but not so many as to be a big problem -- M can't impersonate the website of domain D. Even though he gives you fake DNS (or IP routing, another possibility) he can't present and prove possession of the key for a valid cert for D and the SSL/TLS handshake fails.

Unless of course you, or the supplier of your browser or OS or device on your behalf, trusts a CA that issues bogus certs, for any of a range of reasons. For example, you can find probably a dozen Q&A here and other stack sites about last year's Lenovo Superfish fiasco: they added software to a large number of Windows PCs that used their own CA to MitM your HTTPS connections for the claimed purpose of providing more relevant advertising -- but they exposed the (fixed) CA privatekey and then anybody else could MitM you. They had to publish tools to remove the offending software and CA cert, and to catch any that slipped through the browser and OS makers also blacklisted their cert.


Sounds alright to me. I'll answer your questions and add some thoughts:

  1) You can run a billion iterations of pbkdf2, but if their password is a single character it won't help much. Does this change if there is a mandatory password policy that ensures at least relatively sane passwords?

I personally hate password policies, but I'm not your average user. You could consider warning them (saying 8 characters non-dictionary is a reasonable password) but otherwise leave them free to do what they want. Maybe when they try to use a 3-character password or less, give a pop up going "that one sucks, do you maybe want to leave the file unencrypted instead? [y/n]" ;)

  2) Alternative key generation techniques?

See How to securely hash passwords? for some ideas. They are not strictly key-derivation functions, but I think you can use things like scrypt and bcrypt the same way.

  4) This gives an offline attack method to get their password for the service which has access to a whole lot more than just this file. Seems like this adds substantial risk. Thoughts?

Good point! It does give away offline cracking, but only for one user. In the case that password file gets stolen, the attacker could probably modify the device to include a keylogger anyway.

  3) Overall thoughts/suggestions?

Besides a key-derivation function, also look at how you encrypt the file. You'll want to use authenticated encryption, or at the very least, a block cipher mode of operation (i.e. don't use ECB).
You could also encrypt the file with a randomly generated key (using a CSPRNG) and then encrypt that key with the user's password. If the user wants to change the password, they can do that without re-encrypting all the data. You only have to re-encrypt the key.
Users don't like it when there is no "I forgot my password" option. I am in favor of saying "this is how every file storage service should work anyway so stop complaining" but that's simply not acceptable for many companies. You could encrypt the key (see my previous point) not just with the user's password, but separately also with your public key. Then the password reset feature can use the private key (stored on the server only) to decrypt the key and allow for a password reset. This also means you have access to user's data, though.


How specifically should I implement CSRF protection?

I'd recommend creating a system where an anti CSRF-token is submitted from a hidden input field and is transmitted in the header. Both should be  checked on the server side.

Here's an example in PHP:

function generateToken($key) {
  $token = base64_encode(openssl_random_pseudo_bytes(16));
  $_SESSION['csrf_' . $key] = $token;
  return $token;
}

function checkToken($key, $value) {
  if (!isset($_SESSION['csrf_' . $key]))
    return false;
  if (!$value)
    return false;
  if ($_SESSION['csrf_' . $key] !== $value)
    return false;

  unset($_SESSION['csrf_' . $key]);
  return true;
}

  if ($_POST and $_POST['action'] == "something")
  {
    $header_token = apache_request_headers()['X-Anti-Csrf-Token'];
    $post_token = $_POST['token'];
    $post_token = str_replace(" ", "+", $post_token);

    if ($header_token == $post_token)
    {
        if (checkToken('settings', $post_token))
        {
           // ok; do something

        }
     }
     else
     {
         // wrong; do something
     }

 }

Sending the header before processing it:

   <script>
    $("#some_div").submit(function(event) {
      event.preventDefault();

      var $form = $(this),
        url = $form.attr('action');

      var posting = $.ajax(url, {
        type: 'POST',
        processData: true,
        dataType: "text",
        beforeSend: function (xhr) {
        xhr.setRequestHeader('X-Anti-CSRF-Token', $('#token').val());
    }

This piece of code will generate the token and puts it in an hidden input field.

<input id="token" type="hidden" value="<?php echo generateToken('settings'); ?>">


Found the answer on the same page:

  Let mimeType be the result of extracting a MIME type from response’s
  header list.
  Let destination be request’s destination.
  If destination is script-like and mimeType (ignoring parameters) is not
  a JavaScript MIME type, then return blocked.
  If destination is "style" and mimeType (ignoring parameters) is not text/css, then return blocked.
  Return allowed.

I assume, since there is no MIME type declared, step 3 never returns blocked. In my case, there is no destination either, so we finish in step 5 -> allowed.

Edit: In step 3 and 4 an empty mime-type will not be a javascript mime type or a text/css mime-type. Therefor the request will be blocked if the destination matches.