Recognize site vulnerable for SQL injection Although I understand the concept of a SQL injection and have done simple exploits (simple hack challenge sites and stuff) I'm wondering if one of the site run by my employer is vulnerable.

Unlike my previous experience (relating strictly to forms open for injection) it seems as though the site is sending SQL statements via the url. When manipulating the URL of a page (which is in the form of http://site.com/?action=thefaq_question&questionnr=34&categry=10) by replacing the =10 with =* for example I get error output on the page:

Error in SELECT * FROM thefaq WHERE 1  AND thefaq.site=1  AND  thefaq.id=* : You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '*' at line 1

Error in    SELECT * FROM sitecontent WHERE

etc etc, the error goes on quite a bit.

Clearly SQL statements are sent via the URL, but does this make the site vulnerable by definition, i.e. is it possible there is some input validation taking place that would strip any truly malicious SQL statements from the URL before being executed?

As far as I can tell, if the URL processess SQL statements anything goes therefore it is vulnerable but I want to make sure of this before I make a fool of myself when reporting it to my employer.

---- edit ----

Mentioned this to the appropriate manager who didn't seem particularly stressed about it. Explaining that this vulnerability could result defacement or worse: user info and possible passwords being exposed (assuming they are decently hashed is probably wishful thinking) did not impress him. Website is not a priority (nor is diverting any budget to fixing the issue I suppose).

Thx for replies!

The fact that you can introduce parameters on the URL is not a vulnerability per se. (For example, I love imdb.com for the ability to control with those parameters)

The fact that the sql error is output to the user, AND the fact that the query is actually run against the database shows that the site might indeed be vulnerable to sql injection.

That simple statement is enough to show to your superior that something must be done. For better effect you might want to show a complete exploit case where you run successfully some query that you were not suppose to.


Convenient cross-platform help on checking secure hashes like SHA-256 It is often helpful to be able to obtain a good cryptographic checksum of a file, e.g. the SHA-256 hash.  This can be used to verify file integrity, so long as you have a reliable source for the hash.

Support for both SHA-256 and MD5 from the command line are provided by default in Ubuntu and probably other flavors of Linux and BSD via the sha256sum and md5sum programs.

On a Mac (10.5) I see the "md5" command-line program, but nothing for SHA-256.  Given the hash collision problems with MD5, it is a less-than-ideal choice.

And I can't find any software installed by default on Windows to compute any crypto hashes.  The closest to "standard" I've seen was a Microsoft reference to how to download an optional command line program, File Checksum Integrity Verifier utility which can do SHA-1 (which is still relatively safe), but not SHA-256.

One download that I've run across for SHA-256 is hashcalc for cross-platform GUI support, but I haven't vetted it or tried it.

Am I missing any default secure hash software (better than MD5) for Windows or Mac?
Is there a page somewhere that gives good hashing tool advice for a variety of operating systems?  Ideally it would lead to safe, convenient GUI solutions.

Clarification:
I'm looking for advice I can share with others, which will help them safely work with hashes.  By "safe" I mean something which, for example, a government employee could relatively easily determine to not be too risky.  For example, software installed by default, documented and backed by the vendor, is much less risky than installing some third-party executable off the Internet.  If it has to be third-party software, then something that is vetted and recommended by experts is preferred.

(Cf. cross-platform signatures)

For Windows, you can use PowerShell, which is installed by default on Windows 7 / Server 2008 R2 and onwards. The Get-FileHash function was introduced in PowerShell v4, which comes with Windows 8.1 and Windows Server 2012 R2. For older PowerShell versions, these scripts from James Manning's blog will do the trick.
Example of Get-FileHash usage:
C:\Windows> Get-FileHash -Algorithm md5 .\notepad.exe

Algorithm       Hash                                                                   Path
---------       ----                                                                   ----
MD5             24DA05ADE2A978E199875DA0D859E7EB                                       C:\Windows\notepad.exe

Supported algorithms are SHA1, SHA256, SHA384, SHA512, MACTripleDES, MD5 and RIPEMD160.


Why is ASLR not performed at less than page granularity? What technical reasons are preventing ASLR from being randomized to a byte offset? On Linux it's to a 4kb page and on Windows to a 64kb region.

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


Installed TPM, how to use BitLocker without USB key? I have a Windows 10 computer with 3 hard drives:

Samsung SSD 850 EVO 1TB (SSD, system drive where Windows 10 is installed, not encrypted yet)
First 3 TB HDD already protected by BitLocker
Second 3 TB HDD already protected by BitLocker

Whenever I boot into Windows, I need to type in long passwords to unlock the second and third drives. It's annoying.
So I was excited to finally install this ASRock TPM2-S TPM Nuvoton NPCT650 Trusted Platform Module onto my Z170 Pro4 motherboard (which is running firmware 7.50) today because my understanding was that I would then be able use BitLocker on my system drive too and won't need to keep entering long passwords for each other drive on each boot into Windows.
I do not want to use a USB key. I just want my main Windows password to automatically decrypt all 3 drives when I log into Windows.
The BIOS successfully recognized the installation of the TPM:

And Windows 10 did too:

Here is my problem. When I click "Turn on BitLocker" for my C drive, it forces me to set up a USB key, which I don't want to do:

I have already tried clearing the TPM:

I also tried changing settings in Windows Local Group Policy Editor, but then when I clicked "Turn on BitLocker" for my C drive, I got the error: "The Group Policy settings for BitLocker startup options are in conflict and cannot be applied. Contact your system administrator for more information." (With other settings, I got: “The startup options on this PC are configured incorrectly. Contact your system administrator for more information.”)
What am I doing wrong? How can I enable BitLocker on my C drive without setting up a USB key?

Here are some other screens, which may be helpful:

The operating system needs to claim the TPM. That can be done by clearing it first. After that, the boot process gets attested and the Bitlocker key can be unlocked using TPM. Please note that anytime you change something in the BIOS or the startup sequence or add additional hard drives or USB thumb drives, the unlock key needs to be entered again.


Unix Privilege Escalation: "sudo must be owned by uid 0 and have the setuid bit set" It seems protections are harcoded into sudo that prevent the binary from executing as a low-privileged user. Running it in Ubuntu as a normal user returns the following error:

  "sudo must be owned by uid 0 and have the setuid bit set"

Maybe this is an incredibly stupid question: but what's to stop an attacker from compiling their own custom sudo binary that allows it to execute with any uid?

what's to stop an attacker from compiling their own custom sudo binary that allows it to execute with any uid?

There's a basic misunderstanding going on here.  The program does execute, it just stops when it notices it's not running as the root user.  Recompiling the program to remove the check would only allow you to run the task as the user who executed sudo, not root.  In other words, the check for running as root in sudo is only an error check and diagnostic, not a security feature.

The misunderstanding is that programs don't have any special ability to execute as another user, the extra privilege is a property of the file permissions on the file.  Any program with the setuid bit set will execute as the owner of the file.  If you were to compile your own program the file would be owned as you. While you are allowed to set the setuid bit on your own file, you  aren't allowed to change file ownership without extra privileges.  So setting the setuid bit would only allow others to execute your program as yourself.


Vulnerability or Threat? I have a practice question here:

  A business is going to determine the dangers to which it is exposed. What do we call a possible
  event that can have a disruptive effect on the reliability of information:

  A) Vulnerability

  B) Attack

  C) Risk

  D) Dependency

  E) Threat

I'm getting E) threat for this question but I am a bit confused because vulnerability is what weaknesses there are in a system that make it vulnerable to these attacks.

Can someone clarify if E is correct?

Yes, E is correct.

A vulnerability is a weakness that could lead to harm (whether it be to confidentiality, integrity, or availability.)

A threat is an agent that could expose the vulnerability.

The question is about an "event", which is the threat.


How secure is SSL/TLS, explained in laymans terms? While trying to answer this question it occurred to me that while there's many good answers about the strengths and weaknesses of SSL/TLS in terms a security professional or software developer can understand, there's not many good responses that a layman might be able to properly understand.

For instance, we describe some variants of TLS/SSL as "insecure", which in the security world has a somewhat specialized meaning that might be summarized as "There's some known vulnerabilities that significantly degrade the security, and you should likely disable this variant on your servers.".  A layman might interpret "insecure" as "simple to exploit", which isn't necessarily true.

So can someone provide a good layman's explanation as to the current security level offered by SSL/TLS?  The answer should include the resources of the attacker, the effort, resources, and access involved, and (possibly) the cost.

The answer might also include other ways to achieve the same goal without attacking SSL/TLS, and risks we all take for granted every day.  (My credit card, for instance, was compromised and used for fraud last year when Newegg got hacked)

What kind of security level does TLS provide, as of 2019?

Quite a good security level, under the assumption that the configuration is according to best practice. I'll try to explain what I mean using lay terms. This means I will stray a little bit from technical accuracy to make it more understandable for people who may not have a lot of experience in security.

TLS is not like Coca-Cola, it's like Steak!

When you go to the grocery store, and you go buy a can of Coca-Cola, you expect it to taste exactly like all the other cans of Coca-Cola you have ever drunk before. TLS is not like that! TLS is more like Steak. You had some good ones, you had some bad ones, and all of them taste different, depending on the meat and on how well it was cooked.

What that metaphor should show is that a question like "Is TLS secure?" is akin to asking "Does steak taste good?". The definite answer is maybe! You can have TLS that is considered very secure, and you can have TLS that offers no security whatsoever. Just like how you can have steak that tastes so amazing you will talk about it for a while, and how you can have steak that tastes like somebody put a shoe sole on a grill.

  When do I know if TLS is secure?

The meat of TLS

TLS is based on ciphers, just like steak is based on meat. A cipher is a fancy term for throwing a bunch of cryptographic stuff together, but the details don't matter for a lay explanation. The first ciphers we made were bad. We didn't know how to made good ciphers, but we eventually learned from our mistakes. Modern ciphers are considered "more secure" than old ciphers, because more knowledge went into the new ones than into the old one's. (Just like how the first steak a chef cooks will not be as good as the 1000th steak).

TLS is considered secure, if it only allows good, modern ciphers. Old, bad ciphers can cause problems!

  What does it take to attack TLS?

It depends on the ciphers being used. In the absolute worst possible case, this means that TLS is configured with a NULL cipher, meaning that no encryption or authentication is done at all. This shouldn't be accepted by clients anymore today, but if you run a very old and outdated system, it might.

In a more realistic "worst-case", it could be that TLS is configured in a way to use weak ciphers. While these ciphers are not trivial to crack, a sufficiently advanced attacker (think NSA, etc.) can certainly do it. If really weak ciphers are chosen, then even less sophisticated hardware may be necessary.

  Should I, as a normal consumer, worry about TLS?

Most likely not! Modern phones and operating systems are configured in a way that they only allow good ciphers. The chance of an attacker being able to crack one of those to sniff your traffic is very, very, very small. It is currently not known if any of the Alphabet Boys (e.g. NSA, etc.) are able to crack any of those ciphers.

On the other hand, if you use Android 2.3 or Windows XP, then it is time to upgrade to something more recent. Aside from the numerous other reasons for switching away from a long obsolete system, these operating systems don't support any modern ciphers. To fit with our analogy, they're like a store that only sells horrible old "meat".

The only time you should worry is when you see errors related to TLS. It is most likely an error on the side of the server you are trying to connect to, but it might also mean someone is trying to spy on you.


SHA-1 deprecation and self signed internally used certificates I was wondering whether SHA-1 deprecation would create any security concern for self signed (internally used) already existing certificates. What is the right thing to do in this case? Since the discovered vulnerability does not allow an attacker to create another document with the same hash as an already existing document organizations using already existing certificated should not be effected, right?

Should the SHA-1 hash algorithm still be allowed for this scenario?

Self signed certificates are not affected.

With the ability to create a hash collision an attacker can create two certificate requests, one for legit.com and one for evilattacker.com, with the same hash. The certificate authority will then sign legit.com and the attacker can use the signature to create a valid certificate for evilattacker.com, and vice versa.

With self signed certificates, you control both the request and the signing, so this scenario does not apply. As long as you don't sign certificate signing requests that were created by people you don't trust, you are safe.

It is still a good idea to use newer hash functions for all your future certificates.

Edit: note that you are also dependent on browser behavior if you want to keep using SHA1 certificates.


Why message digest should be kept secret? Why is it required to keep message digest secret? If A sends message M to B,then A will apply hash function to M and will get digest M'.

Now is there any requirement to encrypt M and M'? Assume that B is only concerned about message integrity?

I have learnt that Message digest needs to be kept secret but why so?If A is sending plain text without encryption then why should A cipher digest?

If the message is sent in the clear, then there's no reason to not send a digest in the clear... Except:

Using RSA to "sign" the message (to prove the identity of the person who sent it and the integrity of the message) involves encrypting the hash. This may be what you're reading about.

Since RSA is a key-pair algorithm, you can keep one key secret and make one key public. Therefore, if you encrypt the hash with your private key, then if somebody else decrypts it with your public key and that digest matches the message, then they can prove that you (the only one who has the private key) had to have written the message and nobody else has modified it in the meantime.

In this case, the point of encrypting the hash/digest isn't to hide it, but to use that encryption for proof of identity and integrity.


gnupg keys and pass database - Protecting both from unauthorised access and loss My target is to use pass to store a lot of passwords and be able to access those passwords from wherever I need them, possibly using just a single pass-thing (password, passphrase, my voice, my fingerprint, my eyes, ...), so the short question could be

What is the correct way to use pass?

I've read several guides about that, but none of them (actually none of the ones I understood) deeply analyzes the relation of this tool with gpg (which is required), since it has several implications connected with the fact that files/drives can be stolen as well as broken, and one should procted those objects from the former, the latter, or both risks.

In the original question I described what I've understood so far.

I ask you to help me understand if the conclusions I drawn in the final bullet list are correct?

Original post

I had never used GnuPG intentionally when yesterday I created a keypair, choosing a hopefully bulletproof passphrase.

I did this in order to have an id to use with pass, with which I want to store the ever-growing unmanageably long list of passwords relative to this and that site. So I've installed pass and set it up too, then I inserted all the passwords in the store, and my cat as well.

After this, all I have is basically two directory trees, namely ~/.gnupg set up by gpg commands I used to create the keys, and ~/password-store which I set up and populated by means of pass commands.

Now, my computer could either be cracked (by someone who's desperately in need for my secret cooking recipes), or explode, so I'd like you to help me understand what to do next.

With respect to protection from ill-intentioned people and from physical failure, are the following true?

I have to keep the ~/password-store directory in the devices I use, as long as I need to access passwords from there on a daily basis.
I have to keep the ~/password-store on an external device as well (either one, indestructible or more, redundant).
I don't have to be afraid of 1., as long as the passphrase is not violated.
There's also no need for me to export and upload my public key elsewhere, as long as I don't need to sign messages, but I could (point 6.).
The private key (just like the public one) can not be stolen from my system, but it cannot be used as long as the passphrase is not violated, and I have not exported it (the private key) on a file on that system drive/disk/etc reachable by others.
In order not to lose the public key I have to export it and (either 6.1 or 6.2 is enough)

6.1. copy it on an external device (bla bla), or

6.2. upload it on a keyserver.
I have to export and copy the private key on an external drive.
The passphrase can also be only in my mind, as long as my memory helps me.

More synthetically I think I have to

remember the passphrase (1 string);
store the exported private key (1 file) on a drive safe from thieves;
alternatively store the exported public key (1 file) on a drive safe from physical damage, or on a keyserver;
store ~/.password-store (1 directory) on a drive safe from physical failure, and have it available from wherever I need access to a password (uploading it on GitHub would be ideal, right?).

While I'm not sure there can be a concrete "correct" way of using pass, what you've described is a reasonably safe setup and I think your assumptions (except maybe #5) are accurate.

To use pass to manage your passwords you need to access(from each PC you might use)

A copy of your /password-store/ directory
Your gpg private key

To protect the availability of your passwords you need to back up

Your gpg private key (public is included in the gpg --export-secret-key process iirc)
your /password-store/ directory

While your password files are encrypted and it's (theoretically) safe to leave them in the open I personally wouldn't leave them in an open GitHub repo. If you don't have a paid subscription with them there are other providers that offer private repositories for free (or you could spin one up on your own hardware/VPS).
Another thought I'd add is to consider using a smart card to transport your secret key. It's a convenient way to get the key between different machines you may want to use it from that

Can't be copied as easily as it could be from a regular flash drive.
Doesn't leave the key on the box when  you're not using it (it lives on the card).


Why not use same certificate for webserver TLS and Signing in SAML? I have read a bit about configuring shibboleth, and recommendations for SAML at internet2

I get the point that a certificate does not have to be signed when used for SAML, because actually only the key is needed.
However, I keep seeing people recommending not to use your web servers TLS certificate for signing your SAML requests.

I get that it might cause configuration problems for some types of setups where the clients aren't expected to check the whole certificates chain. But I'm currently using our TLS cert as our SAML cert, and not experiencing any problems, so it seems to work in our case.

Our cert is about to expire so I've started the progress of rolling out a new cert, which involves sending the new public key to the idp.
 Now our idp responds with:

  I prefer to work with a self-signed certificate for SAML-signing &
  -encryption. I see no reason to use the webserver's certificate for this purpose.

And recommends me to create a self signed cert and trying again.

However, other people in my team don't see a reason not to use this cert, and I can't immediately find one myself.
Are there any good reasons against either of these 2 aproaches?

One reason agains creating a self signed cert and using that one is that we then need another check on when this cert is about to expire, and can't forget to do a rollover, whilst now we have a check for the webservers TLS cert and a check for checking this SAML cert might be hard to set up.
Why should we bother to do it if our current setup works?

Can anyone give me some hints to why either of these 2 approaches is a bad idea?

There are a few different reasons. There isn't any one single answer, but they can all be grouped together as: because you're not supposed to use the same key for multiple things.

In this case it's more of a practical issue.

You have to time rekeying the TLS cert with the SAML cert, which can be painful.
Revoking one key means revoking the other.
If someone steals the key they can then impersonate both TLS and SAML.
If someone misconfigures the SP to validate the chain instead of the cert then anyone with a valid cert signed by that authority can impersonate.
etc.


How would you analyze an image to find out if there are scripts embedded in it? How would you analyze an image to find out if there are scripts or possible malware embedded in it? What tools / methods to use?

I am assuming that you're going to be accepting user-uploaded image files and serving them to other users through a web application. In that case there are two different attack vectors here.

(1) files that can be interpreted as both image and another type.

This includes:

(1a) files with embedded HTML tags, which can then be loaded as HTML by a browser that does content-sniffing, and scripting content inside executed in your domain's security context, causing traditional JavaScript XSS.

(1b) files that can be interpreted as plug-in data, most notably Java (GIFAR attack). Just hosting these can get you compromised for XSS because the Same Origin Policy in Java and Flash is based on the location hosting the file, not the including page.

Such files can commonly be valid images of the expected type as well as working as the vulnerable target type.

You can make these attacks difficult by processing submitted images, loading them in and re-saving them. You may be doing this anyway in order to do cropping, resizing or quality-level changes.

It is in principle possible for someone to submit an image that, when compressed by whatever algorithm you're using, pops out an image with <script> or other bad content in, but this is probably quite impractical in reality.

Either way, you should mitigate this attack by serving any user-submitted files from a separate domain that does not have the ability to script or share cookies with the main website domain. (It can be a subdomain as long as there is nothing served on any shared ancestor domain.)

(2) malformed images that exploit bugs in browser image decoders to cause arbitrary code execution. These aren't common today but there have been image decoder bugs in the past and it is possible some more may arise.

This can also be defeated by loading and re-saving the image; even just not getting an error on load is generally a good sign. However, it is conceivable that there could be a bug in your own image decoder, which would then make your server-side vulnerable to exactly the same problems.

So make sure your server-side image processing components up-to-date, and, where you can, limit the number of accepted input formats in order to reduce the attack surface. You may also wish to consider running the image handling in a lower-privilege process (privsep) if this is a likely threat for your app.

Loading an image for processing also carries the risk of server-side denial of service attack through very large images (in size and/or compression bombs). Sanity-check the file size and resolution from image file header before attempting to load.

Depending on what your app is, there may be limited benefit from detecting malformed-image exploits because (apart from their rarity) it's usually easy for an attacker to host them elsewhere and post the image or a link to it in other user-submitted content.


OAuth 2.0, what should it be returned in the authorize endpoint if the client_id is wrong and no redirect_uri is passed We have been working on a OAuth 2.0 IDP implementation, and during the implementation of the authorize endpoint, i couldnt find in the RFC 6749, what should happen if the client_id is not passed in the request or is invalid, and there is no redirect_uri in the request also. Should the server return a 400, with no body, a 400 with json? Or is there a better approach?

Everything is well explained in the request for change you pointed:

The authorization server responds with an HTTP 400 (Bad Request)
status code (unless specified otherwise) and includes the following
parameters with the response:
invalid_request
           The request is missing a required parameter, includes an
           unsupported parameter value (other than grant type),
           repeats a parameter, includes multiple credentials,
           utilizes more than one mechanism for authenticating the
           client, or is otherwise malformed.

And this is typically the case you described, if the request is missing the client_id or the redirect_uri you should return an HTTP/400 Bad Request as described in section-5.2 of the RFC:
  HTTP/1.1 400 Bad Request
     Content-Type: application/json;charset=UTF-8
     Cache-Control: no-store
     Pragma: no-cache

     {
       "error":"invalid_request"
     }


When will TLS 1.2 be deprecated? Just wondering where I can track TLS 1.2, specifically, when will it be deprecated?  A link would be appreciated - thanks!

According to a quick internet search, TLS versions 1.0 and 1.1 were not formally deprecated (unlike SSL 2.0 and 3.0), but rather were declared deprecated by several large internet companies in order to force other vendors to stop using them.
Here appears to be a tracker, but as you may see it does not show 1.0 or 1.1 as deprecated. This type of news would likely be covered on news sites and blogs by major companies well in advance of such a change.


Since I can set the source IP address to anything using raw sockets, does this mean I am untraceable? For homework, I coded a TCP packet with raw sockets. So I was also able to change the source IP address to whatever I wanted. So why can't someone just make a program, which sends millions of these packets (DDoS) with a different source IP address? Wouldn't he/she be "secure" and no one could trace him/her?

Further questions:

Couldn't you just implement this in this DDoS program called LOIC? So there wouldn't be anyone busted using it.
What do the routers log about me (sender)? Could the police trace me with these logs?

You are correct that this is possible. There are problems with the plan though:

The network you are leaving can filter to drop outgoing packets that do not have a source IP from within their network.
DDoS (Distributed Denial of Service) is based around idea that many boxes target a single one, overloading the target's ability to handle the data. Your single consumer hardware is unable to produce the output alone to overload a target.
Source IP address spoofing is used in some denial of service attacks, such as sending small requests for large amounts of data to many servers where the servers will reply to the spoofed target. See Reflected/spoofed attack on Wikipedia or last year's NTP Amplification Attack from the US CERT.
Usually TCP doesn't benefit from address spoofing due to the three-way handshake. It is more useful with TCP to perform session hijacking.


How to tunnel all network communication? I'm looking for a way to tunnel all network communication from my laptop through another computer. I can control the software on both the laptop and the computer. The connection between them should be encrypted.

Which technique should I use? VPN seems out of the question, as I wouldn't want my laptop to show up on the other computer's LAN.

You can indeed use tun/tap tunneling. The easiest way I know of to do so is using OpenVPN. There are graphical clients for that for most OSs.

If you use 'tap' tunneling, your laptop will show up on the remote LAN, since layer 2 network traffic is also sent through the tunnel. Using 'tun' tunneling however, which occurs at layer 3, only your IP traffic is routed to the remote LAN.


What scenario does CORS protect against? My understanding of the same origin policy is that it prevents scripts from making requests to resources outside of the domain from which they originated. One motivation of this is to prevent a malicious script from interacting with any other sites that the user might be logged into (for example, a malicious script from site-a.com might submit requests to the users banking site).

CORS relaxes this constraint since there are legitimate reasons why a script might need to make such requests; resources shared across multiple websites would be one example. In the above case, www.site-a.com might need to access resources at media.site-a.com or api.site-a.com.

One hypothetical way that this could be achieved would be for the originating site to publish a whitelist of sites (in the response headers) to which external requests can be made.

My understanding of CORS is that the browser will submit requests to any resource and depending on the response headers, will allow the response to be read or not; that is, if the response headers indicate that they will allow requests from the origin then the requester will be able to read the response body and otherwise not.

What is gained by the CORS approach of allowing the requests and inspecting the response headers over the hypothetical approach of disallowing the requests in the first place based on a published whitelist?

... publish a whitelist of sites (in the response headers) to which external requests can be made

This would be pretty dangerous. An attacker could simply decide that access from his site to various others is allowed.

Instead the recipient of the request should decide if the request is acceptable or not (i.e. from which origin instead of to which target). This is essentially what the Access-Control-Allow-Origin header in the response to a CORS request does.

Given that the allowed origin for a cross-site request might not be only specific for a site but also specific to a resource on the site (i.e. specific URL vs domain) it makes less sense to publish site-wide information about this in any HTTP response from the site. Instead it makes more sense to publish the relevant information in the HTTP response for access to the specific resource.


OSINT: Geolocation to IP range Usually, in OSINT when it comes to IP addresses and geolocation the investigator attempts to get a rough location from a public IP address. However, I'm trying to find out more about reversing that process. Let's say in this scenario I know the location of the entity of interest, to about the city level. Obviously you can't get an exact IP, just the range of IPs for that location. What tools are there I can use to find out an IP block of a location?

In general, you can't.
IP addresses are assigned to organizations, not regions.  Those organizations may in turn assign address blocks to specific regions, but some don't.  The steps for figuring out what IP address your target might have would go something like this:

Figure out which ISPs operate in the area
Figure out which IP address ranges have been assigned to each of those ISPs.
For each address, do a lookup in your geolocation database to see if it's in the city of interest.

Note that because you're doing many lookups, the uncertainty inherent in geolocation is magnified.  Additionally, your target may be using an ISP that doesn't do geographic assignment (eg. satellite internet), or may be using an ISP not on your list.


XSS payload explanation with x:x/ I am trying to understand exactly how JavaScript XSS (cross-site scripting) payloads found across the internet work and I would like your help for the following:

<img src=`xx:xx`onerror=alert(1)>

">

When are those two (individually) going to trigger the alert?

I'll try to explain this in terms of Reflected XSS

Attacker sends you a malicious link via email, doc, msg etc
You click on it (assume that in another tab you had already opened the same website and logged in, hence a session cookie is present)
The buggy website will reflect back the javascript payload in response that was embedded in the URL that was sent to you
Browser will execute the javascript, usually this javascript will be used to steal the session cookies.

Example for 1st payload:

Request(malicious link) :
http://buggy.com?data=%3c%69%6d%67%20%73%72%63%3d%60%78%78%3a%78%78%60%6f%6e%65%72%72%6f%72%3d%61%6c%65%72%74%28%31%29%3e

And server without doing any check on this input will reflect back the payload in response as:

<img src=`xx:xx`onerror=alert(1)>

This will make browser to create a pop up because xx:xx is an invalid
 source there by executing the script in onerror. In actual attack scenario you will have to replace alert(1) with the your javascript .

Example for 2nd payload:

Imagine the buggy website is fetching the value of lang parameter from the GET request and setting lang attribute of the html response without any checks.

Without payload:

Request: http://buggy.com?lang=en

Response:

lol

With the payload:

Request: http://buggy.com?lang=%22%3e%3c%69%6d%67%20%73%72%63%3d%22%31%22%20%74%69%74%6c%65%3d%22%74%72%75%65%22%20%78%3a%78%78%2f%6f%6e%65%72%72%6f%72%3d%22%61%6c%65%72%74%28%27%74%65%73%74%20%78%73%73%27%29%22%3e%20

Response:

 >

lol

This will make browser to create a pop up because :

1 is not a valid source again
forward slash in x:x/ is simply ignored or replaced with a space by the parser because img tag is a self closing tag
Inside a tag you can have a random string like x:x which will not have any effect on the browser nor it is against the syntax(i did not see any error being thrown in the browser console, someone can correct me i'm wrong)
In actual attack scenario you will have to replace alert('test xss') with the your javascript.


How to track a Spoofed SMS on Iphone A mate pulled a quality prank on me the other day by sending me a SMS via a Spoofed number. He's bought a SMS gateway and can set the message ID/phone number to be 'God' (or whatever he wants(letters or numbers)).
I wanted to see if i could determine the original SMS gateway that it came from, I vaguely remember this used to be possible with Nokia phones several years ago.

I found this:

  How to get the SMSC set in the iPhone? In the iPhone keypad and type
  *#5005*7672# Press Call
  Which told me my network carrier SMSC (which was not helpful)

and this:

  *#5005*78283# This dumps a baseband log in /Library/Logs/Baseband/

Which I couldn't find the dump from (sites suggest looking in App-data folders on Windows machines when iTunes syncs the info.

I figure if I know the SMSC/SMS Gateway number its come from I can tell if its been sent via a legit carrier or sent via a dodgy 3rd party one.

Are there any other ways (that don't involve requesting the telco/ISP) to trace or find information about a message that you've received on your phone? Specifically I'm using an iPhone but I have access to a wide range of other phones.

I'm sorry for the long answer, but I felt it's needed here. Plus, you're not the regular OP looking for a quickie. I've looked into this when we studied GSM in school. The are several methods to find out the SMSC from your phone; however, that's completely different from what you're looking for.

Let's start with how an SMS is sent (very basic description): The sender sends a message sending request to his serving support node. This request contains the message itself, the destination, and the SMSC (the sender's SMSC). The request is then forwarded to the service centre of the SMSC and stored there.

When the message needs to be delivered (usually, immediately after storage in the SMSC), the SMCS' gateway looks up the recipient's information to find the correct route to their MSC/SGSN. The message is sent there, and then forwarded to the actual recipient.

When the message reaches the actual recipient, the only trace-aiding information is the source of the message as it appears to the recipient (effectively, some sort of identifier/address leading to a gateway in the recipient’s network). The races will lead you to your provider, from there on you need to request information from them.

Remember when I said that what you're trying to find is not what you actually need? Well, that's because what you're trying to find is your SMSC which is configured in your SIM card from your provider. This SMSC is used when you are sending a message, but not when you're receiving a message. Even if you find this address/number (not really difficult), there's nothing you can do with it; it's the address/number of the SMSC of your provider.

Bottom line is: To trace a spoofed message, you need to see the logs of your provider's gateway which will lead you to the sender's SMS gateway which will lead you to the sender's SMSC which will lead you to the sender which, unfortunately, will not be the actual sender (your friend) but spoofing service. Then, and only then, you'll be able to be sure that this message was actually sent by a spoofing service.

If you're looking to dive deeper into this, please have a look at the SMS protocol specification 3GPP TS  23.040


Technical security issues with proactively executing a phishing campaign targeting your own users We've had some issues with compromised accounts due to users falling victim to phishing campaigns.

The possibility of us doing a phishing campaign against our own users to proactively shame them has come up.

Putting aside my personal issues with this, I have some security-related problems:

If we use an outside account as the source of the campaign:

Account could be locked by the outside provider---and rightfully so. We will never see the replies anyway.
Replies will be transported via external servers. These replies may contain credentials.

If we use an internal account as the source:

Some users use external SMTP (they shouldn't, but some do). Therefore, still the chance that the reply is transported via a server we do not manage.
It will make the message look "more legitimate" since it originates from our domain. Maybe not a fair test?

My question: Has anyone done this? How did you overcome the technical issues? Any issues you didn't foresee? I am hoping to convince management that this is not a smart thing to do but I want to be prepared just in case.

This depends on the kind of phishing attacks your users regularly fall victim to. If they fall victim to "please email me your credentials", but not to "click this link", you've got some very weird users.

Otherwise, if they fall to both, or if they just fall to crafted links, you can set a local server up and set a phishing site up. This will guarantee that no credentials leave your network, while still allowing the ultimate goal: to figure out who fell for it. This also means that you are a bit more in control as everything happens locally.

However, there are a couple of points that raised an eyebrow:

If some of your users use an external SMTP server, it means that down the line, you either have no SPF record for the domain where the mailboxes are, or you have an overly permissive SPF record. This is a major issue as it makes phishing emails trivial to craft in order to look "good" - all a phisher needs to find is an open relay. Consider adding a restrictive SPF record and telling your users to use your SMTP server (+ TLS or GTFO)
Why do you want to shame your users? Drawing statistics is a much better use of the data. Naming & shaming leads to people being singled out over something relatively trivial (or a mistake we could all make), leads to people leaving for greener pastures.


Do I have a virus on my hosted site? A few weeks ago I hired someone to build for me a very simple PHP site.
I bought PHP hosting and a domain name, and I gave him all the credentials together with the specification of his tasks.

When the deadline was over (it was a really simple task), I contacted him to see some results and he asked me for more time. Finally, I realised that he was not able to do the task, so I told him that I didn't need his services anymore.

Today I accessed the site's main page just to look if I could use some of what he did, but my antivirus blocked me with an alert of some virus called VBS:Agent-KZ[Trj]. (See the image below).

I contacted my hosting provider and they told me that they did not detect anything.

My questions are:

Do you think this guy did something with the goal of harming me?
How can this virus harm me? How dangerous is it?
I am concerned about my email password, because I was logged in my Gmail account in a different tab while I tried to access the site. Should I change my password?

I would appreciate your advice on my problem. Have a look at the image below to see the antivirus warning.

Update

I am struggling with this issue, so far this is what I did:

I contacted the company, but they keep saying to me they find nothing in my documents root. I am sceptical about this, because since it is a shared hosting, I think the virus could be anywhere.
I disabled the DNS server configuration from my GoDaddy admin panel, so if somebody goes to that URL, they will not be infected.
I scanned the whole infected system with Avast and I found a file called f3PSSavr.src in the System32 directory. I managed to erase it and currently I am performing a boot time scan also with Avast. I am curious what that was? And how it came there? I scan my systems for viruses at least once per month and this is new. You think it could come via the infected URL?
My next step, once the boot scan in my laptop finishes, is to erase all the browsers cache.

So what do you think the processes is in order fix the issue?

Perhaps - proving that the developer uploaded a "dropper" would be difficult.  Considering that credentials were provided to the developer, it's possible that the credentials were passed-on or otherwise compromised (the developer's system could have already been compromised).  Regardless, unless you wish to initiate legal action, focusing on the point that your site is compromised and working to clean it is more efficient.
The "malware" can be harmful.  The difference in term is that the dropper app that Avast detected is a way to gain access to your system.  If the malware successfully compromised your system, then it's possible that an attacker have installed a backdoor.  With that said, it looks like Avast detected the dropper so it's possible that the infection attempt was blocked.

You could always try running other malware detectors to see if your system has been compromised.  Otherwise, if you know a good security practitioner, you could always have them take a look.  I'd recommend against going to big-box computer stores - the workers there often have little knowledge or experience in this area (you get what you pay for).

Alternatively, if compromise is a concern, then reimaging the system and reinstalling software only from verified sources (i.e. media, vendor's web sites, etc) will reduce the likelihood that you become re-infected.  Reinfections are common when people backup the binaries and re-install those on a clean system.  Again, this measure is if you are certain that your system is compromised and you want greater assurance that your system is clean.

FYI, if you're interested in learning more about the dropper, look here for other names assigned to this app by other AV/malware vendors.

YES!  You should change your password immediately and while you're at it, make sure that no other apps have been authorized access, password recovery features aren't modified, etc.  Any other sites that use the same password should also be a point of concern - change those password as well (i.e. banking, VPN, etc) - preferably to something that's different.  Password managers (i.e. Lastpass, KeePass, etc) helps manage using multiple passwords for each account.

Good luck


Understanding a TLS 1.3 0-RTT replay attack The specifications for TLS 1.3 0-RTT mention the following threat which an attacker might realize:

  Network attackers who take advantage of client retry behavior to
        arrange for the server to receive multiple copies of an
        application message.  This threat already exists to some extent
        because clients that value robustness respond to network errors by
        attempting to retry requests.  However, 0-RTT adds an additional
        dimension for any server system which does not maintain globally
        consistent server state.  Specifically, if a server system has
        multiple zones where tickets from zone A will not be accepted in
        zone B, then an attacker can duplicate a ClientHello and early
        data intended for A to both A and B.  At A, the data will be
        accepted in 0-RTT, but at B the server will reject 0-RTT data and
        instead force a full handshake.  If the attacker blocks the
        ServerHello from A, then the client will complete the handshake
        with B and probably retry the request, leading to duplication on
        the server system as a whole.

My question is: Where is the attack? At the end of the day, the attacker could as well just have passed his copy of the ClientHello to Zone B and get the same outcome (a full handshake). What am I missing?

You aren't missing that much. I think this cloudflare article near the end outlines possible attack vectors and scenarios quite nicely. Depending on the security of the networks and web apps, 0-RTT may not be responded to pending what kind of parameters or certain types of headers. If an attacker has already figured out how to insert himself and gain visibility to what he would want to replay on a vulnerable host, there are worse risks elsewhere to look out for first. Something like a 0-RTT replay that has parameters and an authenticated session cookie and a HTTP downgrade could be plausible. But in the pentester's world, that's alot of work.


Cracking office documents and other hashes using clusters? I'm trying to figure out how I should go about testing this I just got donated 18 older hp systems that have 4 gigs of ram, and intel core 2 duo processors I believe that they are the ones that came out just before the I series from intel came out. So I'm planning on creating a cluster out of all of these as a fun side project, I do a lot of reverse engineering and I'm just now starting to get into the whole cracking the hash thing. I know how to run various tools like john and oclhashcat, but I have no experience as far as anything cluster related goes. I really would like to know what programs and commands I would need to run in order to do something like this. I have them all hooked up already on my switch so I'm trying to get some advice on what I should do next.

You can build an MPI cluster, which is supported by John the Ripper. However note that even 18 core2duos will probably not be as fast as a 150 USD GPU.


Is changing image's extension prone to error for browsers? In my uploading user's avatar scenario, I change users picture extension to jpg.
Is this making the browsers to act differently? Is it prone to error for browsers when they read users avatar?
Moreover, does it make my web app more secure when an attacker upload a php file?

As @Rook said you shouldn't change the extension as it will cause problems. He also pointed out that the metadata could contain malicious data, which is very true. So here are the steps you should follow, roughly:

Check file size - Is it massive enough to break the web server through DoS?
Check extension - Is it a known extension that you support, e.g. jpg, png, gif
If extension is good, check file header - Even though it says jpg, it could contain GIF/PNG/EXE header, etc
Strip metadata from file - Don't even read it, just delete it
Convert to format of your choice if you want it in a given format

In the event that any of the above checks fail you just stop the process and delete the file and return a simple error message explaining that the image is no good.


When creating self signed certs, is the CA.crt supposed to be installed into client machine? I'm trying to work with OpenSSL C API, I'm relatively new to all this still, and I find a lot of mixed information out there, so I think it's wise to ask for ideas/opinions/clarification.

Anyway, the client program requires a certificate or directory to be loaded which contains a "TrustStore". Is this just another meaning for the server's CA certificate itself in the case I'm creating my own SSL certificates for said server?

And if so, will the intermediate CA work for this purpose in replacement of root CA?

I think I'm on the right track. However, I just wanted some clarification so as to prevent myself making some real daft mistake, as I've heard some conflicting information in regards to this. Some say the client needs the root CA itself; other sources say they only install intermediate CA for security reasons, which seems logical.

I'm generally a little confused as to how the chain of trust works in regards to a client connection though. I've actually only ever needed to generate a CSR and install a certificate on the web server, so the client side stuff is kinda new to me.

This question was originally asked here on Stack Overflow, it was suggested that I ask the info-sec community.

tl;dr If the cert contains some variation of CA:TRUE, it makes sense to distribute it, if it does not, then there is no benefit to distributing it.

The chain of trust itself can be explained in terms of the certificate structure.

If we start from your server's cert (i.e. the cert you would typically use for apache):

you server cert is generated by a certificate authority, based on a CSR you provide. That CSR contains your public key, and some other information the CA may or may not be interested in using.
the CA receives your CSR, and (generally), will create a signed certificate using an intermediate CA. Your certificate will have two public keys: one for the subject (which is the public key extracted from your CSR), and one for the issuing party, which is the CA's intermediate certificate.
the CA's intermediate certificate is itself a signed certificate (with some special options), where the subject key will be the intermediate CA's public key (which is the same public key as is found in the Issuer Public Key of your server certificate). The signing (or issuing) key will be the CA's root certificate (alternatively, it will be another intermediate).
the CA's root certificate is (generally) a self-signed certificate. In practice, this means that the Issuer and Subject keys are the same public key.

You can see this by checking certificates in the wild, e.g.:

$ openssl s_client -connect google.com:443 < /dev/null
CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority

The chain of trust this builds can be summarised as (I am starting from the 'bottom' - the Equifax cert):

the root CA (Equifax) delegates day-to-day activities to an intermediate CA (GeoTrust) and signs a certificate representing this fact (i.e setting CA:TRUE, KeyUsage: keyCertSign). In other words, the root CA 'trusts' the intermediate to issue certificates on its behalf (hopefully after completing a series of mandatory validation steps).
in this chain, the intermediate (Geotrust) has further delegated to a Google CA (CN=Google Internet Authority G2).
the delegate (a.k.a the Google intermediate CA) then signs a CSR, which effectively is a document stating that for a given set of names (the CN, and possibly Subject Alternative Names), a private/public key pair is valid/trusted (the trust here coming from the fact they have validated the claim to speak for a given name - in this case, the Google CA has issued a certificate for *.google.com).

Note that (root) CAs are generally self-signed - a CA is trusted generally because it abides by a set of processes and procedures that are felt to ensure it does not issue certificates to people who should not have them. Which is why I can't go out and get myself a certificate saying I am google.
This is therefore a convention of sorts (albeit one backed by formal mechanisms), and if you start your own CA, distributing its root (and intermediate) certificates achieves exactly the same thing as distributing the certs of other CAs does: it makes certificates issued by that CA be accepted as valid (i.e. trustworthy) by the system.

In more practical terms, the trust store (for openSSL) is pretty much a bunch of files with a specific naming convention. See https://www.openssl.org/docs/faq.html#USER5:

  When a certificate is verified its root CA must be "trusted" by OpenSSL this typically means that the CA certificate must be placed in a directory or file and the relevant program configured to read it

That directory is /etc/ssl/certs (there are others, such as /etc/pki on RH-likes).

https://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu#719047 provides some further overview of how one adds a certificate to the store, as does https://askubuntu.com/questions/73287/how-do-i-install-a-root-certificate,

The short version is that update-ca-certificates automates the process, and is the commonly used tool.

The slightly longer version is that certificates need to be stored by hash (e.g. in files named based on the output of openssl x509 -hash -in cert.pem), so that openSSL can efficiently validate chains.

See https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html for some additional background.

updated to respond to the questions in comments:

The server certificate, in this discussion, is defined as trusted or not based on its chain of trust.
If you think about how (e.g.) curl https://google.com works, it is a bit easier to understand:

curl opens a TLS connection to google, which returns a certificate.
curl looks at that 'end-user' certificate - i.e. the server's certificate, and looks specifically for the issuer.
if the issuer is 'known' in the trust store, the remainder of the trust chain is validated (i.e. the server certificate issuer's certificate is checked, and if it has an issuer other than itself, that issuer is checked, etc). Only if the full trust chain can be validated is the certificate considered valid.

However, it would absolutely impractical to distribute trust chains if end-user certificates needed to be included.
I don't have any numbers on how many websites are out there, but based on the fact Alexa provide a top 1M, you would assume it is more than 1 million.

Which is sort of the point of a chain of trust: you generally need to have the issuer certificates around, but you do not need the end certificates to be distributed, because they tell you who the issuer is.

And you can verify they aren't lying, because you can check the issuers public key (and the chain of trust that establishes it is the proper key), and validate whether the end-user (i.e. server) certificate was really signed by the private counterpart of the issuer's public key.

So no, you should not distribute the end-user certs, but only the chain of trust - or, in simpler terms: distribute all the certs you generate where the BasicConstraints (legitimately) say something at least CA:TRUE.
Do not distribute anything that does not meet that condition, because it is a waste of your time and disk space - everything that does not say CA:TRUE can be validated against something that does.


Using a tabula recta to store passwords Reading an answer to another question ("Is there a method of generating site-specific passwords which can be executed in my own head?") I came across this link, describing a way to use a physical token (a tabula recta with randomly generated characters) to derive different passwords for different sites (choose a cell using the site name and some rule, follow another rule to get the chars that compose your password). I was curious about whether or not that would be a good practice.

The author claims to be an expert in computer security, and as far as I can tell his reasoning looks sound. He does make the caveat that "the security of this system rests on the randomness of the generated characters and the piece of paper." (emphasis mine) In other words, if an adversary gains access to your token, it's over, that I understand (it's easy to show that a dictionary attack can be performed with it*).

However, I'm having trouble determining whether or not the risk of losing the token combined with the consequences of this event would render this practice unfeasible, or whether those can be mitigated somehow. I believe the risk of forgetting a password (especially if not reused across sites, as it shouldn't) is far greater than of being (personally) targeted by a malicious adversary, and password managers are a bit awkward to use. I'd like to know about pros and cons of this technique, and maybe ways in which it can be improved/made feasible (preferably concerning the practical use, I believe the crypto aspect should be self-evident).

*
To perform a dictionary attack, just take each cell of your token (unless you're using a really big piece of paper, there won't be over a few dozen or hundreds of cells) and follow any rule that a human can reasonably follow "by hand" (diagonals, spirals, knight jumps, etc). There shouldn't be many of them (let's be optimistic and say a hundred), and since there will be exactly 1 sequence of N characters starting from a single cell and following the same rule (regardless of N), that leaves no more than 100k possibilities to test for each N (weaker than a 4 character alphanumeric password, for the sake of comparison).

Pros

A password generating token does mean a 'decently' strong password, compared to other manual/memory methods. It does not rely on a common repository of passwords like a password manager. The process is as portable as the token is, which means it could be used in areas where personal devices or internet connections are unavailable, which makes it superior to password managers.

Cons

It would not produce a sufficiently random password compared to automated password generators, but I would not go so far as to say 'not sound security'. A photo of the card is enough to start a dictionary attack, not just theft of the card. Loss of or damage to the card means a loss of all passwords associated with that token.

The other issue is that once someone has your token, they can perform that dictionary attack on all your accounts (and, perhaps with optimizations in pattern/pathing matching once the first successful match was found).

Mitigation

Placing the token in a polarized sleeve so that photos cannot be taken, and physically attaching the token so that it is not easily stolen might help. I was wondering about getting the token printed on a metal card with a hole punched in the corner. Limiting the number of accounts that use the card would also help. Consider printing both sides of a card with different random character sets and distribute accounts across both character sets.

Password Managers

I have used password managers frequently and I do not find them difficult to use or implement.

Conclusion

Both a physical token and a password manager represent a single point of failure and single point of attack, and as such, the impacts need to be carefully considered. Considering the password complexity that could be generated by a token like tabula recta, it might be very useful and more secure than relying on a user's memory in situations where other password reminders are not available.


Why is GPG-agent still caching my passphrase? I can not get gpg to prompt me for my passphrase when I want to decrypt a file. I tried including:

default-cache-ttl 0
max-cache-ttl 0

(also flipped the bit to 1)

within ~/.gnupg/gpg-agent.conf and then running either:
gpgconf --reload gpg-agent or echo RELOADAGENT | gpg-connect-agent or killing the daemon but none of that works.

I wonder if GPG Keychain is doing something wonky under the hood? (Note I am on macOS High Sierra 10.13.6)

gpg (GnuPG/MacGPG2) 2.2.10
libgcrypt 1.8.3

GPG Keychain Version 1.4.6 (1514)

My gpg.conf

# Avoid information leaked
no-emit-version
no-comments
export-options export-minimal

# Displays the long format of the ID of the keys and their fingerprints
keyid-format 0xlong
with-fingerprint

# Displays the validity of the keys
list-options show-uid-validity
verify-options show-uid-validity

# Limits the algorithms used
personal-cipher-preferences AES256
personal-digest-preferences SHA512
default-preference-list SHA512 SHA384 SHA256 RIPEMD160 AES256 TWOFISH BLOWFISH ZLIB BZIP2 ZIP Uncompressed

cipher-algo AES256
digest-algo SHA512
cert-digest-algo SHA512
compress-algo ZLIB

disable-cipher-algo 3DES
weak-digest SHA1

s2k-cipher-algo AES256
s2k-digest-algo SHA512
s2k-mode 3
s2k-count 65011712

My gpg-agent.conf

# Disable agent cache
default-cache-ttl 0
max-cache-ttl 0

Solved the issue.
TL:DR GPG Suite was saving the password in macOS Keychain (not GPG Keychain)

More information here.


Storing users cookies in a database on a server I want to use Apple Push Notification Service, so I need a server. This server will have to check a site every x minutes.

How the site that has to be checked requires the user to login.
So is it ok security wise to get the user to login on a web browser, then upload the cookies   which contain the session information (not the user's username or password) and store them in a database which is just one table, with 2 fields, 'cookies' and 'deviceToken' so that the cookies are associated with the device token.
Then perform requests from the server to the site with the user's cookies, on the user's behalf, and if the site has changed push a notification to the user.

Is this a secure method and how exactly would I implement this so that noone else can get access to the database and download the cookies?

Also as long as I let the users choose to enable or disable push notifications (neither opt-in or opt-out) is this morally ok?

Is it secure?

If the phone->server connection is not encrypted, then those session cookies can be sniffed. If your server->website connection is not encrypted, then those session cookies can be sniffed.

If cookies can be retrieved by the phone, then an attacker could pose as that phone by sending the same device token and get the cookies back, then hijack that user's session.

And finally, if the cookies are not encrypted in the table and somebody is able to steal the contents of that table, then they can hijack all of your users' sessions at once!

Is it morally okay?

Not unless you explain to the user what you are doing and what the risks are.

By copying a user's cookies and sending them to a target website, you are posing as that user. You could (or anybody else who was able to steal those cookies) hijack that user's session and do nefarious things.

It really depends what that "target" website is. If it's a bank, then this is definitely a bad idea. If it's reddit.com, then this may be reasonable.


Have I done enough not be compromised through image uploading I know that you can never be sure that you have done enough to be secure, and I also know that file uploading is hard to make correct. Before asking this question I read some of the related posts here like risk of php image upload, what steps should be taken to validate... and security risks of uploading.

So I think that I have done everything that is needed, but I would be very grateful if someone can take a look at what I have and tell if I have done enough. So I am running the latest PHP 5.5.9-1+sury.org~saucy+1 on Apache/2.4.7. And my uploading method looks as follows:

public static function uploadTemp($number, $file){
    //check if the filename exist and upload was without an error
    if (!$file['name'] || $file['error']){
        return false;
    }

    // check if extension is valid
    if (!Helper::validExtension($file['name'])){
        return false;
    }

    // check is the size of file is valid
    if ($file['size'] > (1024 * 1024 * 6) || $file['size'] < 1024 * 10){
        return false;
    }

    // no need to upload images less than 50x50. Also $file['size'] can be spoofed
    $imageSize = getimagesize($file['tmp_name']);
    if ($imageSize === false || $imageSize[0] < 50 || $imageSize[1] < 50){
        return false;
    }

    require_once('SimpleImage.php');
    $image = new SimpleImage();
    $image->load($file['tmp_name']);

    // saving a file to a temporary directory and renaming it.
    $image->save(Image::$tempDir.$number.'.jpg');
    return true;
}

SimpleImage is an open source tool for manipulating an image, inside of a tool I changed only one thing (function save to save every file with 644 permissions). My $number is a string which is a concatenation of random number and a current timestamp, $file = $_FILES['fileToUpload'] and validExtension looks the following way:

public static function validExtension($filename){
    $extensions = array('jpg', 'jpeg', 'png');

    $arr = explode('.', $filename);
    if ( in_array(strtolower(end($arr)), $extensions) ){
        return true;
    } else return false;
}

My temporary folder has 755 permissions.

So my question is: am I missing something here or is there I way I can improve things:

may be restrict further permissions (I do not need to do anything with images except to view them by the client. The folder is used only for image uploading)
may be changing some parameters in php.ini or apache

// check if extension is valid

is largely pointless. You (wisely) create the filesystem name without any input from the original filename, so the extension is discarded anyway.

Filename extensions are not a globally-observed convention. Even on Windows not everyone uses the same file extension mappings. So it's not usually a good idea to rely on particular extensions.

// no need to upload images less than 50x50

You will want to check that the image dimensions are not too big. Uploading an enormous image (especially a super-compressed one) is a good way to DoS a server.

  My temporary folder has 755 permissions.

Ideally you would want to have the web server user and the file owner user in a group, so you could give it 750 permissions, allowing the web user to write files without giving the same privileges to any other users on the server.

  I changed only one thing (function save to save every file with 644 permissions)

And similarly 640 here, or more likely 660 if you want your owner user to be able to write to the web server user's files.

  The folder is used only for image uploading

Make sure you enforce that on the server level, so that if someone does manage to upload a .php or .htaccess file into that directory, it doesn't do anything. It doesn't look like this code would allow that, but there might be some other flaw somewhere that does.

In general every file/directory that is writable to the web server user needs to be made completely non-executable, either by locking down the web server to do only static file serving from there, or not serving anything from there at all.

If you are having the web server serve the picture out of the upload directory you have a range of potential cross-site-scripting problems:

IE sniffing the contents of the file to find HTML embedded in it and treating it as a web page (with scripting) - can be prevented in more up to date versions using X-Content-Type-Options header;
Java treating the file as an applet, ignoring the real type; Flash treating the file as a SWF, ignoring the real type; the Same Origin Policies of these plugins not matching JavaScript's;
Flash loadPolicyFile treating the file as a crossdomain policy file, ignoring the real type and, in older versions of Flash, malformed content.

You've greatly mitigated these XSS-content attacks by loading and re-saving the image as JPEG, which would disturb the contents of the file, so an attacker can't just include the active content as-is inside the file.

It's not totally impossible for an attacker to submit an image that they know, when PHP re-saves it, will result in chosen malicious content appearing somewhere in file. This would be pretty difficult, especially for a lossy encoder like JPEG, and I've not heard of anyone actually using that in a real attack, but it's conceivable. The JPEG format is not specifically designed to provide hard guarantees about the difficulty of crafting input to generate a chosen output (as a cryptographic hash would).

If you want to be sure there are no possible XSS upload attacks the usual solution is to serve your untrusted data files from a separate domain, so that cross-site-scripting into it doesn't get the attacker into your main site.


Certification 27001 Issue My department already got certification for ISO 27001:2013 last year (2016). But for a particular reason, my department should move to new building. How would be the status for my ISO 27001:2013 Certification.

Do we have to take another recertification audit? or just surveillance audit?

Broadly speaking: As long as you comply with the standard, if your ISMS is still in place as a whole and all your information security processes are working fine your certificate should be fine as well.

You should definitely evaluate all changes that come with the move itself. If there are any major developments within your infrastructure or your organization, then your ISMS will probably be affected as well. You have to react to these changes properly.

You should also contact your certificate authority and ask them, what their expectations are, in a case like this


Is using an access token for authentication a bad idea Is it right that if there is a malicious browser extension allowed to "Read and change all your data on the websites you visit." on the users's machine an access token can be potentially leaked no matter how securely you store it ?

If the user has a malicious browser extension, then there is nothing that a site owner can reasonably be expected to do to secure that user's information.

Properly using session and access tokens to identify a user after authentication remains the best practice, even when the user's machine is compromised.  This OWASP Session Management Cheat Sheet gives a good overview of these best practices, and the OAuth standard is battle tested for most general-use identification purposes. Secure the token as securely as you can, and remember that you can't blindly trust the remote machines.


Do people use "phising" as a real term, or just a mistaken spelling of "phishing" Is "phising" a commonly accepted term, or just a mis-spelling of "phishing"?

I've always understood "phishing" is a common security term. However, recently I've started seeing serious articles and people using the word "phising" (without the second h) as if they are serious.

For example, this entire page:
http://ferruh.mavituna.com/ssl-implementation-security-faq-oku/ [link is now dead]

or this SO question:
https://stackoverflow.com/questions/4365294/is-redirecting-http-to-https-a-bad-idea

It's a misspelling. Even in both links.

  phishing (M-W Online)

  a scam by which an e-mail user is duped into revealing personal or confidential information which the scammer can use illicitly

Might not be the best proof, but only 1.2% of all the Google results are for "phising" versus "phishing". I seriously believe this is human err. Furthermore, this is a relativity newer term, so it makes sense for things like this to happen.


Does investigating the .eml file of an email suffice to deem it malicious? Let's say that I want to test whether an email in my inbox is safe or not. Can I tell this with 100% certainty just by investigating the .eml file or are there some other places to check for absolute certainty?

When I mean safe I mean safe from all possible attacks but mostly code that targets some exploit in the email client.

EDIT No2: So far the answers for my question are associated with the deception of the user (i.e phishing techniques). What about the aspect of exploiting the email client vulnerabilities? Will the evidence of such an attack exist in the email source? Also in my question I ask how to investigate the email for its safety and not if someone can send me an email pretending to be safe.

No. There are some SMTP fields like

  MAIL FROM: - generally presented to the recipient as the Return-path:
  header but not normally visible to the end user, and by default no
  checks are done that the sending system is authorized to send on
  behalf of that address.

also

  From: Joe Q Doe  - the address visible to the recipient; but again, by default no checks are done that the sending
  system is authorized to send on behalf of that address.

Anyone can spoof any existing mail address. I could even send you a mail from your own mail address.


Can DES-based hashed password be recovered if salt is known? Can a hashed password be recovered if the hashing is done with DES based crypt function in PHP and both the hash and salt are known by the attacker?

Consider the following example:

$salt = 'mysalt';
$pass = 'mypass';
$hashed_pass = crypt($pass, $salt);
// $hashed_pass = myDUAMR/WMo7.

I know that John the Ripper can break this, however it's not going to return the password, but instead it will return a string that can be used to create the same hash value. Can the real password be recovered in the given scenario?

John the Ripper works by trying out possible passwords, very quickly. It will not always break a DES-based crypt, or at least not easily.

With the DES-based hashing function, passwords may have up to 8 characters, and only 7 bits are used for each character (the upper bit is ignored). Considering that the password is typed at some point by a user on a keyboard, one can assume that there are 95 possible values for each character (ASCII characters from space [32] to tilde [127]), hence 6704780954517121 potential passwords (that's 1 + 95 + 952 + 953 + ... + 958). It is quite a lot; enumerating all possibilities on a PC will take at least a few weeks. But it is still technologically feasible.

DES is an encryption function, but the DES-based crypt is not DES; the internal function is altered (by the salt, namely), executed 25 times, and, more importantly, the roles of the key and the message are swapped. The end result is that the name "crypt" is improper (though traditional): this is no longer an encryption function; it should be called the "DES-based hash". What this means is that there could be (and indeed there are) two distinct passwords which hash to the same value (even if they use the same salt). For instance, this blog post shows that with the salt "hi", both "cqjmide" and "ifpqgio" hash to the same value "hiH9IOyyrrl4k" (the blog post claims this to be the first publicly known such collision, which shows how much the problem is interesting since it is not hard: these are 64-bit values, so the cost of finding a collision is about 232 invocations of crypt(); that the first published collision appeared only in late 2010 just proves that nobody actually tried before that).

(Note: contrary to what the blog post says, the possibility of finding collisions has no influence whatsoever on the security of the password hashing system. The DES-based hash should not be used any longer not because of the ease of producing such collisions, but because it has too small input and output spaces, and is too fast.)

Consequently, from the salt and hash alone, there is no way to pinpoint "the" password, because the information is just not there. Through enumeration of all possible passwords, one can build the list of matching passwords, but there is no way of telling which is the one the user thought about. However, and that's the important point here, the machine which uses the result of the DES-based hash in a password verifying system cannot tell either: any password which matches the salt and hash value is a good password, as real as any other. If the salt and hash are "hiH9IOyyrrl4k", then both "cqjmide" and "ifpqgio" are accepted: even if you thought your password was "cqjmide", I can still log in under your name by using "ifpqgio" as password.

Note, though, that the vast majority of possible hash values have a single matching password, hence exhaustive search will find that password and none other.

On a similar note, since only the first eight characters are used, you could have a 40-character long password, out of which the last 32 characters will be totally ignored by the DES-based hash. There is no way to recover those from the hash value since they are simply dropped and have no influence whatsoever on the computed hash.


Are there any tools for automated penetration testing of Silverlight applications? I'd like to find a tool to assist with automated penetration testing of Silverlight applications, in a similar vein to AppScan for webapps.

Specifically, I'm looking for a tool that can cope with sending requests to binary RIA service endpoints.

Do such tools exist?

Short Answer: No (though with the speed of the web, by the time you read this things might have changed...)

Long Answer: There are several that may be helpful, but I haven't tried them

WCF binary soap plugin for Burp Suite
SoapUI


Giving merchant account information to web programmer Our web programmer needs our merchant account information to set up our ecommerce site.  He is asking for the "processor name", "processor ID" and "merchant ID".  If I provide him with the information is he going to be able to access our merchant account and take money out?  ie. charging refunds to his credit card.

Could you be more specific as to your situation? How is the web programmer in question related to your company? Is he a permanent staff or a contractor? A proper contract should protect you reasonably well from such threats.

In more technical terms, there is no reason why your programmer needs your actual credentials. Sites like PayPal provides sandbox environments to test out transactions without actually involving actual money. Your programmer should be able to code the transaction system and provide a configuration interface where you can add in the actual details yourself later on.


What is ECDH public server param reuse? What is ECDH public server param reuse?

"ECDH public server param reuse" is when a server uses the same DH key value for multiple handshakes, instead of generating a new one for every handshake. The DH should be "ephemeral", that is why it's called "DHE" or "ECDHE", and this means the key is single-use and should never be reused.

Generating a new NIST P-256 ECDH or X25519 key is cheap, so there is no need to reuse it for performance reasons, but some SSL accelerator appliances do that. This is bad and they should be patched/configured to not do that.

@Mohamad

I have answered your question. It seems you do not know how TLS works. There are good explanations on this site about how TLS works. ECDHE uses a cleartext channel to establish a shared secret between two parties, then RSA or ECDSA signatures are used to establish identity of server or both server and client, then authenticated encryption (AEAD) is used to protect confidentiality and ensure data was not modified in transit.

"ECDH public server param reuse" refers to a small thing (about a single line of code) that is done wrong by a TLS server. It violates the forward secrecy property of ephemeral DH. It might be done on purpose, to enable decryption of traffic immediately by an appliance or later from an archive. It might be a performance optimization. It might be indication your software or firmware needs an update. It might be a configuration issue. Without more information, we don't know.

A TLS server has a great many lines of code, most of which are important to security. Unfortunately, it is possible to deploy an interoperable implementation that has some of those wrong (or missing). So the software/appliance seems to work (Chrome connects to such a server, or your client is able to connect to a standard server like Apache or IIS), but actually has a security problem.

A bunch of common errors/issues have names, and this is one of them.

If you know the general layout of an implementation, you should know where this line of code is. If you know the configuration API of a library or the configuration UI of an appliance, you should know where the toggle is.

Your question is a little of an XY problem. Tell us what you actually have and what you want, and we will be able to help you. For example, if you manage/operate a web site and you used Qualys SSL Server Test tool and got this issue, and you tell us how TLS termination is done for your site (e.g. version of MS IIS, version of F5 appliance, etc.), we might be able to tell you how to fix it.

I see you're an ASP.NET developer. Versions of MS IIS that have the "ECDH public server param reuse" issue do not have a configuration that can affect this. The software does this by design. The DH key is cached and regenerated periodically, but not for every connection, for performance reasons. Since the key is not stored on disk and is not completely static, it's not so bad, but it's not great. Possibly newer versions of IIS don't do this, but I don't know.


Is there a way to store user files without being able to decrypt them? I'd want to build a secure file storage web application.

Currently ordinary password authentication is used for login. After login this password is used for encryption and decryption of user files at server side. Thus only this user has access to them.

But user can't be sure that:

a man at server side isn't able to decrypt them
files are actually encrypted.

Is there a way to store user files securely and solve those problems?

Note that users should be able to access files not only from one computer.

If you want to make sure that the server isn't able to decrypt the file, you must not reveal the password to the server. Therefore

the encryption password must not be used for server-side authentication;
the data must be encrypted on the client side.

You can build complex architectures, but fundamentally, if you don't trust the server, don't give it your password.

An simple web application (server-side PHP plus client-side JavaScript) that does this is ZeroBin. I recommend reading this write-up on Ars Technica about a site based on Zerobin. ZeroBin does not perform any authentication, which may or may not be what you want — this is just an (open source) example to illustrate the principle.

In order to have confidence that ZeroBin does not reveal your data to the server, you need to review the JavaScript code that is executed in the browser, and convince yourself that it performs as advertised.

Alternatively, if you want to perform the encryption server-side, you need to assure yourself that the server is secure enough for your needs. That means you need to trust (or have some third party (that you trust) verify through an audit) that:

The server does not store or leak passwords.
The server code behaves as advertised; in particular, it only stores encrypted data and promptly erases any temporary copies of plaintext.
The data in transit is properly protected.
The server is physically secure, so that no intruder can access your data or your password while it is in use.
People with legitimate access to the server (e.g. system administrators) are trustworthy.
This state of things will remain true as long as you use the service.


Encrypt and Data-Integrity: h=CRC-8(m) and c=Encrypt(k,m) then send (h,c) over a channel. Secure? m := plaintext message
c := Encrypt(k,m) (AES-128 in counter mode)
k := Key (16 Byte)
h1 := CRC-8/16/32(m)
h2 := CRC-8/16/32(c)

1. If i send (h1, c) over a channel, is this secure?

A CRC-8/16/32 is linear dependent, and we build it over the plaintext so I guess I can somehow get some informations about m or k only having c and h, right?

2. If I send (h2, c) over a channel, is this secure?

That can't be better, because if so its really easy man in the middle could simply create a valid (h2,c) pair, while if we send (h1,c) he need to know the plaintext to calculate a valid CRC?

Question

If there is a system, like the two mentioned above, how can a man-in-the-middle attack the system? Some examples and/or math is appreciated!

I know that you can't use a CRC for authentication in a real system, it is a theoretical question. There are people out there using CRC instead of real MAC. I just want to understand the risks of the (bad) CRC solution. (in detail with math)

Both of your schemes are flawed, and that is not because of CRC. If you replace the CRC with a cryptographic hash function, then your schemes are still insecure.

hash(m) + Encrypt(m, k)
One is the purposes of encryption is to ensure confidentiality of the plaintext message. A message can only be revealed by cracking the 128-bit key. In contrast, the hash is independent of the key. If the number of possible plaintexts is limited, then an attacker can easily brute-force the plaintext.

Since the hash function does not take the key as input, and AES is secure against known-plaintext attacks, there is no way to gain any information about the key from the hash.
hash(Encrypt(m, k)) + Encrypt(m, k)
The hash function here does not guarantee the authenticity of the ciphertext, because anyone can calculate the hash. Unlike the previous scheme, this hash does not reduce the security of the encryption.

If your objective is authenticity, modify the second scheme by using HMAC instead of CRC.
Or don't use a separate MAC and use AES in GCM mode instead of CTR.


If the Charles SSL Proxy shows me sensitive data, is that data insecure/exposed? Today I was exploring a website used for keeping track of student grades and everything related to school. Basically like a school progress tracker for your child which is used by 90% of schools in my country.

I fired up Charles proxy and connected my phone to it and installed Charles's root certificate so I can use https (the site uses it). Anyway, I logged into the site and checked what Charles captured.

It captured a simple ajax call with 4 fields containing all the login credentials. Here's a screenshot:

Everything is even labeled - uporabnik means "user" and geslo means "password"
So if I am understanding this correctly (I am really really just a beginner), everyone that manages to capture this can look at it?

Is this only possible with a proxy or can wireshark for example also do this and just capture packets over wifi?

Are my assumptions true and if they are, what should I do about it?

You seem to fundamentally misunderstand what TLS does.

TLS takes the regular plain HTTP traffic and encrypts it and adds integrity checks. Together with the certificate of the server, this ensures

Confidentiality: An attacker who captures the network traffic can not read the content of the communication.
Integrity: If an attacker modifies the network traffic, this would result in errors.
Authenticity: You can be sure that your communication partner is the server you think you communicate with. (We get to this in a second.)

If you were to look at the underlying HTTP communication, you would see your username and password in plain text, because this is what you have sent to the server.

What does the proxy do now?

If you use a TLS Proxy such as Charles, you essentially communicate with the proxy and the proxy communicates with the web server. So what stops an attacker from just using a TLS proxy? The certificate!

When you installed the TLS Proxy, the proxy generated a new CA-certificate, which you then imported. This means you gave the proxy the authority to create a certificate for any domain. For the purpose of being a proxy, this is fine.

An attacker however would have to make you import their certificate (or steal the private key of yours!) so you would trust certificates by their proxy.

So, is this an issue now?

No, it's not. Everything is working as it's supposed to.
At the end of the day, when you send your username and password to a website, it somehow has to actually reach that website.


Can a CSRF CAPTCHA be defeated? One defense that developers use to protect against a CSRF attack is to implement a CAPTCHA in critical steps.  A CAPTCHA ensures that a human is at the keyboard approving the activity.   But I've heard that CAPTCHAs have been broken.  Sure, I can see how the CAPTCHA-defeating software could be used by bots to post spam to forums and such.  But I don't see any techniques that could be used in a CSRF attack.

Can anyone explain exactly how an attacker can defeat a CAPTCHA in a CSRF exploit?

To clarify ... I understand how CSRF works and the various methods of protecting against them. What I want to know is how the CAPTCHA protection can be defeated.

A CAPTCHA would not be defeatable as an XSRF mitigation except by brute force, or another type of attack (eg clickjacking to frame the target site's UI in a redressing context). Image analysis could not be applied because an attacker from another site doesn't have read access to the content in the CAPTCHA.

However!

  One defense that developers use to protect against a CSRF attack is to implement a CAPTCHA in critical steps.

I don't know the developers you're talking about, they don't sound very sane.

You get the same benefit without the cost in degraded user experience by simply sending a token to the client and having the same token checked when it comes back to the server. (You can also get much more entropy in such a token than a user could comfortably type in a CAPTCHA, making it brute-proof.)

Per-session synchronizer token pattern


Many Websites, one server, which port to use? I've recently been doing some research on pentesting websites through metasploit. Now I've run into a problem that I'm sure is pretty common but I cant seem to find anything else about it on stackexchange.

Say that I am trying to access pentest.com through metasploit and that website is hosted on a service like Cloudfare. Lets say that Cloudfare also hosts johnsbaking.com on the same server. pentest.com and johnsbaking will share the same IP - which would mean that connecting to the IP adress would not actually access the needed website.

So it would seem that the different websites are accessed through different ports(or maybe not?)...but how would one tell which port is being used for which website? Keep in mind that cloudfare does not allow access to a website through ip adress and port in a browser.

In your example the target website is determined by the HTTP Host header, not the TCP port.

On the transport layer it is indistinguishable whether you want to connect to pentest.com or johnsbaking.com. (I assume you implicitly choose the default port which is either 80 for HTTP or 443 for HTTPS.)

Your web browser sends the target host name on the application layer as part of the HTTP protocol. This information is communicated via the Host header. How the header works is detailed in this answer. So instead of setting a different port, you need to exchange the IP with the host name in metasploit.


Why did PHP 5.6 change how it handles SSL certificates? I was using PHPMailer to send an email with SMTP. This time I used PHP 5.6. I received the following error.

Warning: stream_socket_enable_crypto():
Peer certificate CN=`*.example1.com' did not match expected CN=`mail.example2.com'
in /usr/share/php/libphp-phpmailer/class.smtp.php on line 344

Researching this led me to this question, that mentions the PHPMailer docs which say this:

  In a change from earlier versions, PHP 5.6 verifies certificates on
  SSL connections. If the SSL config of the server you are connecting to
  is not correct, you will get an error like this:

It has this work around suggested:

$mail->SMTPOptions = array(
    'ssl' => array(
        'verify_peer' => false,
        'verify_peer_name' => false,
        'allow_self_signed' => true
    )
);

But it goes on to say

  ...this is not recommended:
  You can also change these
  settings globally in your php.ini, but that's a really bad idea; PHP
  5.6 made this change for very good reasons.

What are those very good reasons?

With PHP 5.6 the default for using TLS was finally changed to verify certificates by default and verify them properly (i.e. not only certificate chain but also hostname). About the same time similar changes where done in Python (version 2.7.9).

These changes were done because not properly checking a certificate makes the connection vulnerable to man in the middle attacks. But, relying on developers to add the functionality to properly check certificates does not work because it seems to work without too so why add additional work to make it more secure. This means that having the secure behavior enabled by default is the only acceptable option. Additionally, both Python and PHP did not even have a way to properly check certificates before, i.e. all they could in an easy way is to to check certificate chain but not the hostname.

It is probably no coincidence that these changes were made while many sites switched to HTTPS in aftermath of the Snowden affair and because the revelations of this affair showed that sniffing and hijacking of improperly protected connections was not only a theoretical thing but that government agencies actually made use of it.


Role-Based Access Control Disadvantages According to NIST, RBAC models are the most widely used schemes among enterprises of 500 or more. What happens if the size of the enterprises are much larger in number of individuals involved. In other words, what are the main disadvantages of RBAC models?

The main disadvantage of RBAC is what is most often called the 'role explosion': due to the increasing number of different (real world) roles (sometimes differences are only very minor) you need an increasing number of (RBAC) roles to properly encapsulate the permissions (a permission in RBAC is an action/operation on an object/entity). Managing all those roles can become a complex affair.

Because of the abstraction choices that form the foundation of RBAC, it is also not very well suited to manage individual rights, but this is typically deemed less of a problem.

The typically proposed alternative is ABAC (Attribute Based Access Control). ABAC has no roles, hence no role explosion. Yet, with ABAC, you get what people now call an 'attribute explosion'. The two issues are different in the details, but largely the same on a more abstract level. (A cynic might point to the market saturation for RBAC solutions and the resulting need for a 'newer' and 'better' access control solution, but that's another discussion.)