The distinction between GET and POST isn't just about safety. In terms of REST (the principle underlying HTTP), the GET method is a "retrieve the information specified in the URL" operation while POST is a "do something to the resource named by the URL" or sometimes "do the operation named by the URL" operation.

If your operation is safe but is not an information retrieval, then it is semantically incorrect to use a GET operation. If your information retrieval requires a query that doesn't fit into the URL length limit, then you probably need to structure your data better so your queries should be less complex. Your clients would appreciate not having to shuffle around a complex data structure just to retrieve the information they need.

Having the same resource operated on by multiple HTTP methods (a "mix") is very common and recommended in REST. Each method generally does different things to the resource, for example you might have an API where you have PUT /transaction/1 creates or updates an uncommitted transaction, PATCH /transaction/1 schedules additional actions to an uncommitted transaction, while POST /transaction/1 executes the transaction and marks it as committed, and GET /transaction/1 to retrieve the transaction detail.

There are many cases though where not all methods make sense in a resource. In that case, you would probably want to issue an HTTP 405 Method Not Allowed response.

  Should I forbid GET for non-side effect POST by default?

Generally, you don't want to. That you even think about doing so usually indicates that you might have a design smell or you might have a non-REST API.


Does anyone know about how LinkedIn was compromised?

It was almost certainly SQL Injection.  This is really the best tool when it comes to a hacker reading information out of the database.  Its easy to say "oah we sanitize user input",  but it only takes missing quote marks on one variable,  or forgetting a single call an escape routine to leak 6.5 million password hashes.  Parameterized queries (when used properly) effectively stops these common mistakes.

That being said not every password leak is SQL Injection.  The recent IEEE leak was due to an HTTP log file on their FTP server.  Insecure logging or not being careful with a database backup can also lead a huge leak such as this.  As a pentester I see these mistakes all the time.


The CA is used for signing the certificate which then gets used inside the HTTPS connection. The CA is not involved in the validation of the trust chain of the certificate since this validation is done using the locally stored (and trusted) copy of the CA's certificate (root CA).

The CA will be involved when revocation checking is done using OCSP: If the OCSP responder does not work then the revocation check will temporarily fail. The failure handling depends on the browser, configuration and type of certificate. Usually browsers simply continue when OCSP checks cause temporary failures (i.e. unknown if certificate is rejected). The only exception is usually the revocation check for Extended Validation (EV) certificates, but browsers can often be configured to do strict OCSP checks in other cases too. Chrome is known for not doing OCSP checks but using some other source for revocation checks, but it might be that it will still use OCSP in case of private CAs.

Note that failure of the OCSP responder could be partly mitigated at the server side by periodically retrieving a new OCSP response from the responder and attaching it to the SSL handshake (OCSP stapling). In this case the browser does not need to ask the OCSP responder and thus will not have problems if the responder fails. Of course this can only be done for a limited time, because the stapled OCSP response has a limited lifetime.


Software is too complex

This is by far the most important factor. Even if you just look at something like a web application, the amount of work hours put into the codebase is immense. The code works with technologies, who's standards are pages over pages long, written decades ago, and which offers features that most developers have never even heard of.

Combine that with the fact that modern software is built on libraries, which are built on libraries, which abstract away some low-level library based on some OS functionality, which again is just a wrapper for some other OS function written in the 1990s.

The modern tech stack is just too big for one person to fully grok, even if you exclude the OS side of things, which leads to the next point:

Knowledge gets lost over time

SQL Injections are now 20 years old. They are still around. How so? One factor to consider is that knowledge inside a company gets lost over time. You may have one or two senior developers, who know and care about security, who make sure that their code isn't vulnerable against SQL injections, but those seniors will eventually take on different positions, change companies or retire. New people will take their place, and they may be just as good developers, but they don't know or care about security. As a result, they might not know or care about the problem, and thus not look for them.

People are taught the wrong way

Another point is that security isn't really something that schools care about. I recall the first lesson about using SQL in Java, and my teacher used string concatenation to insert parameters into a query. I told him that was insecure, and got yelled at for disturbing the lesson. All the students in this class have seen that string concatenation is the way to go - after all, that's how the teacher did it, and the teacher would never teach anything wrong, right?

All those students would now go into the world of development and happily write SQL code that is easily injectable, just because nobody cares. Why does nobody care? Because

Companies are not interested in "perfect code"

That's a bold statement, but it's true. To a company, they care about investment and returns. They "invest" the time of their developers (which costs the company a specific amount of money), and they expect features in return, which they can sell to customers. Features to sell include:

Software can now work with more file formats
Software now includes in-app purchases
Software looks better
Software makes you look better
Software works faster
Software seamlessly integrates into your workflow

What companies can't sell you is the absence of bugs. "Software is not vulnerable against XSS" is not something you can sell, and thus not something companies want to invest money in. Fixing security issues is much like doing your laundry - nobody pays you to do it, nobody praises you for doing it, and you probably don't feel like doing it anyways, but you still have to.

And one more final point:

You can't test for the absence of bugs

What this means is, you can never be certain if your code contains any bugs. You can't prove that some software is secure, because you can't see how many bugs there are left. Let me demonstrate this:

function Compare(string a, string b)
{
    if (a.Length != b.Length)
    {
        // If the length is not equal, we know the strings will not be equal
        return -1;
    }
    else
    {
        for(int i = 0; i < a.Length; i++)
        {
            if(a[i] != b[i])
            {
                // If one character mismatches, the string is not equal
                return -1;
            }
        }

        // Since no characters mismatched, the strings are equal
        return 0;
    }
}

Does this code look secure to you? You might think so. It returns 0 if strings are equal and -1 if they're not. So what's the problem? The problem is that if a constant secret is used for one part, and attacker-controlled input for the other, then an attacker can measure the time it takes for the function to complete. If the first 3 characters match, it'll take longer than if no characters match.

This means that an attacker can try various inputs and measure how long it will take to complete. The longer it takes, the more consecutive characters are identical. With enough time, an attacker can eventually find out what the secret string is. This is called a side-channel attack.

Could this bug be fixed? Yes, of course. Any bug can be fixed. But the point of this demonstration is to show that bugs are not necessarily clearly visible, and fixing them requires that you are aware of them, know how to fix them, and have the incentive to do so.

In Summary...

I know this is a long post, so I am not blaming you for skipping right to the end. The quick version is, writing exploit-free code is really really hard, and becomes exponentially harder the more complex your software becomes. Every technology your software uses, be it the web, XML or something else, gives your codebase thousands of additional exploitation vectors. In addition, your employer might not even care about producing exploit-free code - they care about features they can sell. And finally, can you ever really be sure it's exploit free? Or are you just waiting for the next big exploit to hit the public?


How to exploit CSRF using HTML form to save data?

When exploiting a CSRF vulnerability, you are changing the state of the server (i.e. writing). You are not stealing data (i.e. reading). The browsers same origin policy (SOP) is preventing you from reading the HTTP response.

It sounds like you found an endpoint with no CSRF protection, but all it does is returning sensitive data without changing the state of the server (like adding a user, deleting a record or whatever). That is not exploitable with CSRF.

You are talking about saving data in a file on your computer. An CSRF attack is executed on the victims computer. If you are somehow reading data and sending it to your computer, it's not a CSRF attack. CSRF may be part of it, but there must be something more going on.

I recommend you read up on CSRF attacks. Here is a good article.


How to support secure creation of a user account over an external API via a queued job?

This appears to break down to simply;

I have a job queue containing plaintext passwords.
I would like to prevent other server users from accessing those passwords.

This seems like it should be quite easy, assuming 'other server users' does not mean a superuser account.

What you need to do is engineer it so that your frontend <-> jobqueue link acts as a diode, jobs are able to go in, but no data can egress from the jobqueue in the direction of the front end.

Some simple examples;

The job queue exists in a database to which the front-end does not have access. The data is encrypted under a key generated at run-time.
The job queue exists only in RAM in a process marked as untracable (in Linux you will need AppArmor and I believe this is possible by removing the capability CAP_SYS_PTRACE)
The job queue does not exist - make the back-end calls synchronous.

That said, doing anything other than immediately hashing plaintext passwords is antipattern imho.


I am certainly no expert on NTP, so I can't give you a full answer, but:

delorean expects you to specify an interface via its IP address, as opposed to the name that is displayed in ifconfig. This was what kept me busy for a couple of hours when I tried the tool ;) Maybe you are having the same issue?


Is there a reliable way to simulate "Evil Maid Attack" boot path tampering when using bitlocker?

Bitlocker is vulnerable to much the same attack.

This paper describes an attack against the PIN: "At the next boot, the MBR boot loader loads this ﬁle and transfers control to it. A fake BitLocker prompt is displayed (see ﬁgure 1); the entered PIN is stored in the NTFS partition, the original MBR is restored and the system rebooted. Later, the entered PIN can be read from the NTFS partition."

The major finding: "Using a TPM for key management in a straightforward way provides only very limited protection against a dedicated attacker. None of our attack strategies targets the TPM as such. They all exploit the way it is being used by one particular implementation of disk encryption". Which leads me to believe that TPM is not, in principle broken, but that we have yet to develop a system secure against an adversary who is physically present.


Is Strong email validation really necessary?

There's no need for excessive validation.

An invalid e-mail address is just an invalid e-mail address, and any decent SMTP software can handle this. In fact, if you're using a library like PHPMailer (which you should), it will check the address before it even passes it to the actual SMTP service.

Of course one might come up with a scenario where an entirely broken backend somehow chokes on invalid addresses. But then it might choke on specially crafted valid addresses as well. You'd rather fix the backend then try to work around the problem on the frontend.

Sure, basic validation makes sense, because it provides defense-in-depth, increases usability and reduces the amount of unnecessary work. But going beyond filter_var() isn't necessary. By the way, I'm not aware of any bugs in this function. It's more restrictive than required (e. g. comments aren't allowed), but it should indeed catch all invalid addresses.


Does Google use extended validation certificates?

Note: I work for CertSimple, which specialises in verifying site owners for EV certificates.

The answer is no. Google does not currently use Extended Validation certificates. Apple, Microsoft, Twitter, GitHub and most banks do. Google does not.

Why doesn't Google use an EV certificate?

Google does include a verified legal identity in their certificates - the google.com certificate is an OV certificate, which, like EV, asserts Google Inc as the owner of the public key in the certificate - thanks @lie-ryan for noticing this. OV is a predecessor of EV, but does not show any visual indicators of the identity to the end user.

I run a company that specialises in EV. Having had many conversations with Google staff about EV (and having some idea of the culture from having worked for Google in the past), the answer is typically one or more of the following:

Google's own certificates are checked by Chrome itself. Unless your Chrome binary is altered it's very unlikely you'll see a fake Google certificate.
Until recently it was difficult to get a working SSL cert for google.com.mg or google.com.im, as even domain validation CAs would do some minimum work to check for well known companies when issuing certs. This has changed as CAs now entirely automate the process and do not perform any more validation work than what the baseline requirements include.
Inertia: Google's original certificate was issued when 90's era background checks were replaced by domain validation by the CAs.
Requirements for wildcard certificates - EV requires all domains be verified by the CA and included in the certificate as SANs. While the cost wouldn't be an issue (Google run their own CA), the change in process would.
Belief that end users will notice the difference between DNS domains. Imagine the following sites pop up in your browser:

A https://www.google.co.uk/?gfe_rd=cr&ei=ZAjHVp-sCerW8ge956_YBA

B https://www.google.com.im/?gfe_rd=cr&ei=ZAjHVp-sCerW8ge956_YBA

C https://www.google.com/?gfe_rd=cr&ei=ZAjHVp-sCerW8ge956_YBA

D https://security.googleblog.com/

E https://googlehelp.com/

F https://www.withgoogle.com

If it wasn't obvious, A, C, D and F are controlled by Google Inc, B and E not.
Belief that EV background checks are is slow, painful and expensive. This is true, though we are working on addressing this.
Google does not have any data on the effectiveness of Chrome's EV UI and is this unsure of how effective it is.
The CAs have behaved incredibly poorly in the past - companies selling IE5 support until 2015, 'seal in search' injects logos into Google search results pages, Symantec's 2015 miss-issuance and subsequent non audit. Many of these things are profoundly user-hostile. As a result, there is mistrust between the browsers and CAs and even things that are pro-user, such as helping Alice connect to Bob's Bank Inc get caught up in the friendly fire.
Due to to the AMP project hosting content on google.com for prefetching purposes, a lot of full-page content not controlled by Google is now hosted on google.com. This includes phishing content (specifically, fake Google oauth pages). Having an EV certificate for a site with user generated full-page content could harm users.

Responding to the inaccuracies of the current answer

  Google wants added security in a technical sense, not visual cues.

Extended Validation is not added security by visual clues: it is added security by background checks, which assert the connection between a legal identity and a public key.

HSTS and HPKP keep users safe from all known attacks other than a local system compromise

This is incorrect. EV puts a legal entity inside the certificate, in the organization and jurisdictionOfIncorporatedName fields. These are then shown to the browser. If someone registers yourbank.com.mg, or yourbank.com.im, or any other domain they will be able to get a 'domain validated' certificate. However they will have a much harder time passing the EV background checks. HSTS and HPKP will not prevent the browser from connecting to the fake site.

instead Google created HSTS and HPKP

This is incorrect. HSTS, HPKP and EV serve different purposes: HSTS prevents protocol downgrade attacks, key pinning prevents certificate misissuance, EV provides association of a legal entity to the certificate. These are different goals and a solution to one categorically does not help with the others.

EV is marketing. It doesn't provide anything.

This is incorrect. From the EV guidelines

  The EV Certificate Warranties specifically include, but are not limited to, the following:

  (A) Legal Existence

  (B) Identity

  (C) Right to Use Domain Name

  (D) Authorization for EV Certificate

  (E) Accuracy of Information

  (F) Subscriber Agreement

  (G) Status

  (H) Revocation

Note that domain validated certificates do not assert any connection between a certificate and a legal entity. ie, the DV certificate on yourbanklogin.com doesn't make any assertion that the site has anything to do with Your Bank Ltd.

EV signals that the CA claims to have done more work in return

This is misleading: the CA has done more work. Additionally the CA's work is audited for compliance against the EV Audit Criteria Guidelines


What's the recommended way to store at-rest, symmetrically encrypted customer data?

What you are proposing sounds reasonable.

The salt is on the small side of sufficient but still adequate. Increasing it to 12 or 16 bytes wouldn't likely hurt (salt length isn't closely related to performance) and may make the system a bit more secure.

As far as number of iterations, the advice is as many as you can tolerate. So increase the number of iterations until performance becomes a problem.

A key size of 32 sounds great.

It is unclear to me if you need the digest created in steps 4 and 5. Your comment mentions a concern about tampering during transmission, but if you are using SSL (and if you're not then you basically have no security), the transmission should be secure. So I don't really see a need for it. Especially if you are storing and transmitting the encrypted data and digest together. Perhaps if you stored the digest on a separate site, it could help prove that there wasn't tampering (intentional or otherwise). But I don't see it helping in your situation.

While you probably just didn't bother to mention that you are saving the salt in your question, I'll mention that you must save it so that you can recreate the 32-byte encryption key for decryption.

Generally, this sounds reasonable.


Are you wondering if such technology exist, or are you wondering if the speech of a company you know but for some reason do not mention is realistic from a technical point of view?

No matter what, such company exist, an example would be Amourcard. I do not know if there are other, they claim to be the first to offer such service.

This company targets more specially the NFC world, which is subset of RFID used mainly for credit card and passport:

  Armourcard electronically jams the frequency these credit cards &
  epassports communicate over (13.56MHz)

NFC technology does not cope with noisy environment. I mean that if the communication frequency is full of garbage information, the communication between the NFC reader and the tag will not be possible.

This card goal is therefore to produce such garbage information. Internally it is most probably exactly the same kind of circuit you may find in NFC enabled credit card, but instead of implementing the NFC communication standard it just endlessly send garbage as soon as an NFC reader tries to communicate (by the way, on their OOperating Instruction page, section 'Tap & Go' payment gateways, they acknowledge that this behavior may lead several readers to crash and reboot).

At least in principle, this should effectively work for the designed purpose, which is protecting NFC enabled credit cards and passports, as long as this jammer card is stored together with them,
It may be less efficient with other kind of RFID tags, even if they operate on the same frequency, due to protocol or technical differences,
It will not be effective at all with RFID tags operating on different frequencies than 13.56MHz.

Quick addendum: while browsing the site of the aforementioned company, I see that they made the choice for their jammer card to embed its own battery instead of relying on the NFC reader signal like classical NFC tags. They announce a battery life within 18-24 month. Be sure to check the battery status regularly (a green led lightning up when you temporarily disable the jamming feature by holding your finger on a small "button" on the card), since when the battery deplates you will not be protected anymore maybe without noticing it (the card needs to be replaced by new one, no way to replace it).


You've hit it pretty hard on the head of the nail here and driven it home. It doesn't make sense. This really only matters if some sort of other filter is in place to prevent connection, and it wasn't present on this one. Even then you'd still probably have a key in place to make sure no one can snoop on plaintext. It just doesn't make sense to do this.


Changing cipher list of a ctx object after connection establishment

Changing the SSL context does not affect the current SSL session which was created using the context object. The cipher for the session gets set during the TLS handshake and is valid until the end of the TLS session.


Is it possible to have a man in the middle with SOCK5?

Proxy servers would provide no protection against a MITM attack, since your attacker could MITM your connection to the proxy, or the proxies connection to the internet.

  by turning my HTTPS connections into HTTP

The bit about arp poisoning is correct.  Your assumptions about HTTPS are a bit misguided.  It is designed to be used on an untrusted connection, and is not easiy downgraded to HTTP.  It provides authentication and encryption.

To enhance security disable weak HTTPS cyphersuites, and make sure that you type https://facebook.com into your browser.


How to understand "Encrypted Data" in TLS message type?

You should probably start with a general overview of how TLS works. We have a good introductory post here:
How does SSL/TLS work?

To answer your question: every time a new TLS connection is opened, you will see something like this message exchange in Wireshark:

The Hello and Key Exchange messages are to set up an encrypted channel that only the client and the server can read. They will not send any important data until the encrypted channel has been established, after which all communication between the two will look like the Encrypted Data packet that you see. This is TLS working as intended.

As @TorstenS points out in their answer, Wireshark has the ability to decrypt TLS traffic, but you need to be in control of either the client or the server so that you can extract the session private keys and give them to Wireshark.


How can I be sure my former employer no longer has access to my computer?

First of all if this is your personal computer and you have serious suspicion someone is abusing your computer, file a complaint with the police. Accessing your computer without your consent is considered a crime in most countries.

If your employer did not have access before to your computer, chances are you are the victim of computer criminals. Here as well file a complaint with the police.

Then the best thing you can do is reinstall your computer from the ground up. You can backup your files though, just not the executables.


How to get public key of a secure webpage?

This command will show you the certificate (use -showcerts as an extra parameter if you want to see the full chain):

openssl s_client -connect the.host.name:443

This will get the certificate and print out the public key:

openssl s_client -connect the.host.name:443 | openssl x509 -pubkey -noout

If you want to dig further, this question might be of interest.


SSH keypair works in Putty but not in OpenSSH inside the Putty's session

Putty uses its own privatekey format, called PPK, which is incompatible with OpenSSH. You can use puttygen to convert PPK to OpenSSH format (which is also OpenSSL 'legacy' format); see https://unix.stackexchange.com/questions/74545/what-difference-between-openssh-key-and-putty-key .

ssh unfortunately assumes any error reading a keyfile must mean the password is wrong, so it repeatedly prompts for the password when it can't parse the file at all.


how can this prove a clickjacking vulnerability?

Imagine facebook could be placed in an iframe. I could make a webpage with a button that says "win free bicycle!", and above that place a transparent iframe with my facebook page so that the like button is exactly above/covering the "win free bicycle!" button. If somebody clicks on that button, he will not win a bicycle, but he will instead like my facebook page without noticing it.


Security evaluation of Vasco's Digipass Mobile SDK for OTP?

I don't know about 'Vasco Digipass Mobile SDK OTP generator' particularly, but I have evaluated Software OTP generators in the past and these are things I would look at.

Is the app protected by a PIN?
If it is protected with a PIN, then what happens when you key in a wrong PIN? Does it still generate an OTP or does it report an error message.
The relevance of this question: An OTP generator uses a secret key which is shared with the Authentication server. Now the secret key has to be stored somewhere on the device & hence it's vulnerable if the device is lost. Hence it's better if the app is protected with a PIN.
Now next question is where is the PIN stored? If the PIN is stored on the device then the protection again becomes meaningless. Because just like the secret key, the PIN also would be vulnerable to attack if the device is lost. So what's the alternative? First alternative is to use the PIN to encrypt the secret key & not store the PIN on the device. However, this is still not a good method because, once the device is lost, it can be brute forced. So what's the better alternative. The OTP generation uses both the PIN & secret key as inputs to the OTP generation algorithm. In this case, if you type the wrong PIN, then the OTP is still generator because the app does not know if the PIN is correct or wrong. However, if you type in the wrong PIN, then the OTP generated would be wrong. Because the Server would be generating the OTP with the right PIN and hence it wouldn't match the one generated by the app. i.e. the PIN is implicitly verified and not explicitly verified.
So how would you know if your app stores the PIN locally or uses the PIN to encrypt the secret key, then app typically gives an error message when you type in the wrong PIN. Whereas, if the PIN is not stored locally, then the app doesn't give an error message with the wrong PIN.
What algorithm does the OTP generator use?
Does it use a Time based algorithm or an Event (Counter) based algorithm. Hardware OTP generators always usually use a Time based algorithm, but a lot of Software based OTP generation apps use Event based because the assumption is that the time on the mobile device may be off - may not be in sync with the server time.
How is this relevant? Event based OTPs never expire. Or actually they expire only when they are used or when a more recent OTP is used. If you use your OTP generator app to generate an OTP now, you can note down the OTP & use it after any number of days as long as you haven't done any other authentication in between. i.e if you generate 2 otps & note them down, then if you use the 2nd OTP for an authentication, it will work, but the 1st one automatically expires.
Since Event (Counter) based OTPs do not expire they are a little more easily offline attacked then the time based OTP. Is there a mitigation for this. There is another Event based OTP algorithm called OCRA (Challenge Response based). Here the server throws a challenge which has to be input into the app before it generates the OTP.
IMHO, for a mobile device (where you may not be able to use Time based OTPS), an event based one which uses the Challenge Response mechanism may be better than a plain Event based one. However for lay users, it may be a little confusing.
How is activation done?
Is the shared key sent over SMS or something like that? That may make it a little insecure. Some OTP generators are activated by negotiation - i.e. the client and server negotiate the shared key using some standard like DSKPP. These may be more secure than the ones where the key is sent over SMS.


Domain SSL encryption from client to DNS Server

... why the domain name is not encrypted when a request do a DNS Server is made.

DNS is an old protocol which predates the massive use of encryption on the internet. It was designed at a time when the peers in the network were usually considered trusted or at least not malicious. There are actually alternatives which encrypt the names, like DNS over HTTPS, DNS over TLS or DNSCurve.

  And could we solve the USA net neutrality problem with just encrypting the domain name?

Net neutrality is more about preferring one kind of traffic against other kinds and less about blocking illegal content (which is usually explicitly allowed even with net neutrality). Even if you encrypt the domain name the source and target IP of the connection, the used ports and the traffic pattern  are still visible to the ISP and can be used for categorization of traffic. Also, the ISP might let preferred customers mark their traffic in a specific way so that it gets priority. Thus, hiding DNS from the ISP will not help much with net neutrality. It might help with privacy though, i.e. making it harder for the ISP to use or sell behavior information about your internet usage.


Does disabling .htaccess improve security?

Disabling .htaccess doesn't in itself provide any additional security benefit to your website. As @Xander mentioned the primary reason I've seen .htaccess disabled is performance (although I would suspect the performance improvement is negligible in many cases).

However from the hosts perspective it could provide some security benefit, in that it may help protect the host (and any other users on the box) from you. If you the "untrained" user misconfigure a directive in .htaccess it could cause problems for other things running on the box. And in that sense it also helps prevent you from accidentally compromising your own site.

Now whether this is of any practical value, given that there are better ways to handle this, is an entirely different question.

In addition to the options mentioned by @gowenfawr. You could ask your host to add the configuration directives that you want in the .htaccess directly to the server config of your site. That would allow them to confirm that the configuration won't cause a security compromise.


Validating security log configuration (rsyslog and syslog-ng) for PCI DSS 10.5

It seems to me like you're overanalyzing the issue - PCI DSS doesn't require you to ensure that the system is impossible to abuse, it requires you to perform due diligence along some basic abuse vectors.

Cites here are from DSS 3.1 "Testing Procedures":

  10.5.1 Only individuals who have a job-related need can view audit trail files.

Ensure that auth* type logs are readable only by root.  That can be pretty simple:

$ grep authpriv /etc/rsyslog.conf
# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure
$ ls -l /var/log/secure
-rw------- 1 root root 1085793 Nov 10 13:43 /var/log/secure
$

And you're done.  Is it possible that a malicious administrator could go out of their way to log authpriv somewhere else and have it be obscure to see where, and to also have that be world readable?  It's possible, but that's not what the QSA is looking for, they're looking to ensure you didn't misconfigure your logs by mistake so everyone can read authpriv.

(edit) The situation you describe in the comment:

  The issue with checksumming was that applications had valid needs to
  alter the configuration (in places that do not affect security logs)
  and that broke the checksum.

should actually be easier to address with rsyslog:

system logs are specified in /etc/rsyslog.conf, standardized and auto-maintained across systems by cfengine.
rsyslog.conf includes /etc/rsyslog.d/*.conf
application log configurations go into /etc/rsyslog.d/application.conf

In this manner, you can easily prove that your system configuration for logging (say) authpriv is correct, and that the configuration is common across systems.  The per-application customizations are isolated to the /etc/rsyslog.d/*.conf files, which you don't need to checksum or prove to your QSA - he may look at one or two, but in general, he will trust you as an administrator not to hide a redundant bad system-level configuration in the application-level config files.

Again - PCI DSS wants you to document you're doing basic things right.  They're not trying to force you to prove, beyond a shadow of a doubt, that there's no way for you to do anything wrong.

  10.5.2 Current audit trail files are protected from unauthorized modifications via access control mechanisms, physical segregation,
  and/or network segregation.

Show that your log files aren't writable to any inappropriate groups or 'other':

# find /var/log -type f -a \( -perm -g+w -or -perm -o+w \) -ls
131282 2220 -rw-rw-r--   1 root     utmp      2265216 Oct 30 09:51 /var/log/wtmp-20151101
133888  192 -rw-rw-r--   1 root     utmp       192000 Nov  9 16:12 /var/log/wtmp
#

wtmp is group-writable to utmp to allow it to be updated by non-root terminals, so that's normal.  No other findings.  Along with basic checks to show that your logs go to /var/log, you're all set.

  10.5.3 Current audit trail files are promptly backed up to a centralized log server or media that is difficult to alter.

  10.5.4 Logs for external-facing technologies (for example, wireless, firewalls, DNS, mail) are written onto a secure, centralized, internal
  log server or media.

First, show the configuration indicating that logs are sent to your central SIEM.  Then show a query proving that logs from your machine can be found on your SIEM.  Repeat for whatever sample size your QSA requests.

You don't need to do a full reconciliation that every line found locally is found on the remote server.  You just need to prove that you've configured it to log to a remote server, and that it apparently functions properly.

  10.5.5 Examine system settings, monitored files, and results from monitoring activities to verify the use of file-integrity monitoring
  or change-detection software on logs.

Confirm that /etc/rsyslog* and /var/log/* are monitored by your FIM (e.g., Tripwire).  That's it.

Are these steps enough to secure your environment?  No!  The PCI DSS is a floor, not a ceiling.  It's a basic, due-diligence checklist to get you started and to try and ensure everyone is at least buckling their seat belts.  So you can keep looking for ways to improve your security, but you'll likely pass your PCI audit on your way there.

Now, that being said, I'm detecting another issue in your question, which is that you lack centralized configuration control.  That's going to make your audits harder - when you say "here's the config file, and here's the Puppet config showing it's used by 95% of our servers" you make it easier for the QSA to sign off on a sample of your environment.  If you've got "valid configurations [that] tend to proliferate" you've got a problem that's not just impacting your PCI compliance, it's going to impact your overall security.  You should look into centralized management (here's a comparison of four of such tools).


What security holes are introduced by clicking an unknown link?

Assuming there are no remotely exploitable vulnerabilities in your browser (including any of the plugins), in your AV software, in your operating system, in your router... there's no danger. :)

I am being coy, obviously, but I'm not bending the truth by much. If you're keeping your workstation software updated, chances are you're pretty immune against most things the Internet would be throwing at you. Drive-by exploitation attempts sent out en masse (or self-propagating ones, like worms) usually try to exploit old vulnerabilities, in hopes to catch people who haven't been applying security updates.

On the other hand, if you're a valuable enough target for someone to be targeting you directly, then you have to be a lot more cognizant and careful about clicking random links, because someone may attempt to use so-called "0-day" exploits on you. These would be exploits that are either not known to security researchers, or known but without known fixes/AV signatures/etc. Security-conscious people usually have a sandboxed environment (a fully isolated virtual machine, for example) for opening links they deem suspicious, but it's obviously overkill for most people. Your browser includes significant defences against malicious content that could be harmful to your system, and if you've been careful about keeping your operating system and your browser updated with the latest patches, you're probably okay.


Can an HTML-based patient report be HIPAA-compiliant?

Yes, an HTML based report can be HIPAA compliant.

The format in which the report is presented has no significant consequence to compliance. The behavior of the system that is generating the report is what you should be focusing on.


The issue is if you accept user input as part of the url you output, as in this example given by OWASP:

link

The attacker does not have to break out of the URL context, but out of the string, eg by injecting:

foo" onload="evilJS();" foo="bar

or to break out of the a tag as well:

">


Public key: that's the easy part, it can be almost anywhere (known URL, some type of file store like S3/GCS/..., even source control). The only concern is to make sure it is not modified, but it can be read by anyone.

Private key: this is where it gets tricky.
The private key should be as safe as possible with access as limited as possible.
If someone reads your private key, they can pretend to be your service. You are correct that it must not be in source control.

You'll want to make sure the private key is always encrypted. The issue now becomes how to give your service the passphrase to decode the key. The encrypted file itself can be in a cloud storage system (S3, GCS, etc..). Some access controls on the encrypted file is still a good idea.

Some ways to access the passphrase (definitely not exhaustive). Each has pros and cons. Which to use depends a lot on your environment and balancing automation vs security.

environment variable: many deployment systems allow you to specify environment variables in a way that is not easily read by anyone but administrators of the system. This might not be safe depending on the production environment and who has access to the VM/orchestration system.
manage your own: use your own infrastructure to distribute secrets. Things like keywhiz and Vault can be very powerful, but these are not simple systems to deploy and manage.
cloud KMS: make use of the cloud-specific Key Management System (eg: Google/AWS KMS, Azure Vault, etc...). They usually cannot store a file, but they can store a key with which to encrypt a file. The permissions on key usage should be very restricted, this can usually be done per role account and assigned only to your service.
human interaction required: require that someone manually login to the system and decrypt the private key for use by the backend. The obvious downside is that there is no automation there, if your VM goes down it cannot be automatically restarted.


The most likely possibility is that your browser was mis-identifid as Windows NT for some reason. Google treats logins from the same device but a different browser as a new login, for security purposes, and alerts you. It's quite likely that this login was legitimate but just improperly identified.
Another potential is that some malicious app stole your Gmail login credentials, and used it to sign in with a spoofed user agent string.
Either way, I strongly suggest taking the following precautions:

Go to Device Activity and check what devices are logged in. Log out any that you aren't using any more, or don't recognise.
Go to Security Checkup and perform all the steps there. Particularly pay attention to third-party access, as many malicious apps will gain access to your gmail, add themselves as a third-party app with full access to your account, then delete the alert emails from your inbox. This gives them persistent access even if you change your password.
Start using a password manager. I recommend KeePass, but there are lots of options.
Perform similar checkups on any of your other accounts. A compromised email account means that an attacker can reset passwords on other stuff. If you've used this password elsewhere, make sure to change it on those services. Most social media sites have their own security checkup pages.
It's technically covered by a previous step, but I want to emphasise that you should enable 2FA. It's really important, particularly on things like Google accounts, Microsoft accounts, Apple accounts, anything with monetary value (banking, Steam, Amazon, etc.), and any social accounts (Facebook, Twitter, Reddit, Slack, Discord, etc.) that might be used by an attacker for spam. If you run any web hosting or domains, check over those accounts too and enable 2FA where supported.
Check HaveIBeenPwned to see if your email address appears in any password leaks. Chances are the answer is yes. Use this to think about where you might have reused passwords that were used in any of the compromised services.
Check your outbox and deleted emails on gmail. If your account was compromised it may have been used to phish people in your address list, or to send malware to people. Ask your friends to keep an eye out for anything strange coming from you online.


Using Single Domain Name to Identify Multiple Servers Improves Security? (Google's use of 1e100.net)

Each production IP address has a unique hostname, which is predictable, consistent, deterministic, and entirely useless to anyone but a few engineers who I suspect can read these addresses like a map. These names matter a lot to those people; but for the rest of us we just care that it doesn't create new problems.

That's where the XSS comes in, because domain names matter a lot in security. On the web, a domain name is a security boundary. Cookies, browser objects, and other resources are shared freely within a domain but can't cross that boundary without certain provisions. So if each address had a hostname ending in "google.com" or "youtube.com" or any other domain that has associated web resources, then theoretically an attacker could request a resource that normally would be outside of the trusted domain, but which is also accessible through the IP's assigned hostname.

Rather than finding and fixing all such potential issues, a safer solution is to put the hostnames on their own unique domain which is never used for any other purpose and therefore can't harbor unwanted surprises.

It's also interesting to note that not all of Google's IPs use 1e100.net. Addresses under user control like those assigned to Google Compute instances resolve back to a name ending in googleusercontent.com.

  Disclaimer: I work for Google.
  Reclaimer: This is not an official Google response. I don't speak for Google. These thoughts and opinions are my own, and don't reflect those of my employer, my congressman, or the 80's rock band, Toto.


New credit card security standards regarding PA-DSS Compliance

So, do we need to be since we are not
  storing, transmitting or processing
  the credit card data. We are
  transmitting the credit card
  information only from RAM to an API
  call.

Your second statement is contradicting the first, and more importantly, holds the answer to your question.

PCI DSS v2 states the following,

  PCI DSS applies wherever account data
  is stored, processed or transmitted.
  Account Data consists of Cardholder
  Data plus Sensitive Authentication
  Data, as follows:

  Cardholder Data includes:

  Primary Account Number (PAN)
  Cardholder Name
  Expiration Date
  Service Code

  Sensitive Authentication Data includes:

  Full magnetic stripe data or equivalent on a chip
  CAV2/CVC2/CVV2/CID
  PINs/PIN blocks

and I would presume that transmission of the credit card number (which constitutes handling of card holder data) to the third party application would render your POS software to be compliant as well. The question is whether your software should be PCI DSS or PA-DSS compliant, and that is addressed in the section on the "Relationship between PCI DSS and PA DSS":

  note the following regarding PA-DSS
  applicability:

  PA-DSS does apply to payment applications that are typically sold
  and installed “off the shelf” without
  much customization by software
  vendors.
  PA-DSS does not apply to payment applications developed by merchants
  and service providers if used only
  in-house (not sold, distributed, or
  licensed to a third party), since this
  in-house developed payment application
  would be covered as part of the
  merchant’s or service provider’s
  normal PCI DSS compliance.


Why are some ports reported as closed by nmap?

Usually the reason a port will appear as closed is that there is a no service listening on it but the firewall is not filtering access to the port.

In your case this may be because a piece of software has at some point requested that these ports are opened and now no longer uses them?

If you want to change this I'd suggest looking at the windows XP firewall rules (instructions here) and removing any exceptions that you don't think are needed.  After that you should see things as filtered.


Is the WannaCry source code public?

No. It is not.

That is why malware researchers have been laboring to reverse engineer the ransomware functionality using tools such as debuggers and disassemblers. For some malware, source code may eventually leak out, and it makes life easier for a malware researcher, but in general all we have is a binary or a DLL.

  I thought it would've been made public by now.

That depends on the original authors of the ransomware and whether they consciously or accidentally leak the source code, or if they have a security breach and the code is stolen from them. They did not consciously or accidentally leak it yet or have it stolen as far as I know.


Malware stole an executable file on my computer? Seems unlikely

The most important part of this post is "with antivirus".

Do you have automatic submissions turned on?  If so, those computers might have sent in an 'automatic submission' to the AV mothership at some point. It might have been flagged for evaluation, and possibly run in a controlled environment to see what behavior it would exhibit. These environments are often global, as sometimes malicious software does different things if run from a different subnet/country.

The other possibility (discussed by others) could be that it's random port scan or POST engine looking for vulnerabilities on the particular port you are using.  You should enter the IP addresses that are contacting you into an abuse list, and see if they are known scanners.

Mike


Can strangers use Wifi to dial calls from my phone?

In general, no.  To a large extent, Bluetooth can be though of as a wireless replacement for the cables connecting your headset, keyboard, etc. to your phone; the hypothetical device involved works by imitating the phone keypad.  Wifi is strictly a replacement for your network cable; your phone does not accept user-interface input from it.

That said, it's possible that specific smartphones have security vulnerabilities that permit a webpage or other network-delivered content to force the phone to dial a premium-rate number.


This simply means that all these domain names are associated with the IP 17.178.96.59.

Several domain names can be associated with the same IP address. This is common with name-based implementation of Shared web hosting service:

  Name-based

  In name-based virtual hosting, also called shared IP hosting, the
  virtual hosts serve multiple host names on a single machine with a
  single IP address. This is possible because when a web browser
  requests a resource from a web server using HTTP/1.1 it includes the
  requested host name as part of the request. The server uses this
  information to determine which web site to show the user.

  Source: Name-based - Shared web hosting service (Wikipedia)

(Emphasis is mine)

In your particular case, all these domain names seems to belong to Apple; it's not surprising as Apple have to reason to share that single IP with anyone else. As of today, it looks like they all redirect you to the Apple webpage, but they could have done it otherwise. You could have got different website with these domain names, even though they are associated with the same IP.

As schroeder said, one reason to register several domain names that looks similar is to avoid phishing or brand abuse (e.g. typosquatting). I would like to add that another reason can be to correct user mistakes (e.g. https://googl.com/ redirects me to https://google.com/).

Note that my last paragraph doesn't involve that these domain names are associated with the same IP. My example with googl.com and googl.com shows it. But it's possible.

PS: You mention the domain name 12diasdepresentesdeitunes.com.br, I don't get it when I type your command, so I can't comment on that.


Webhook sending Purchase Details to handling Purchases from a Third Pary Service Secure?

tl/dr: If money is involved then you need a way to verify your webhook
transactions.  Your security keys, however, are probably fine,
although in the end that is a business decision for you to make.

Private webhook endpoint
Your concerns over a private webhook endpoint are quite valid.  In fact, this is one of the biggest dangerous for webhook endpoints - you need to verify that the person calling your endpoint is the person who is supposed to be calling the endpoint, and not an attacker.  It's especially critical for online ordering or anything that costs money.  Some systems verify the call by providing an API call where you send back the request you received to the intended sender for verification (aka a triple handshake), and some perform it with cryptographic signatures.  There are probably more ways to verify it, but verification is very important.
Obviously you can and should keep your webhook endpoint a secret, but this is more akin to a "security through obscurity" step, and not a super secure one either.  After all, any developer who has access to the code base will be able to find out what the webhook endpoint is.  You're also in trouble if your application code becomes public or accessible to an attacker, or if one of your own developers becomes an attacker.  Since half of all data breaches start internally, this is a very real concern.
Unfortunately there isn't anything you can do unless the provider gives you options.  I would push hard with them to see if they have any options for webhook verification.
Leaked purchase key
Leaked purchase keys are a danger but also a more fixable one.  You do want to make sure your keys are long enough that they can't be easily brute-forced.  That has the disadvantage that it makes them hard to type into an app, so you might try to figure out a solution where users can enter the key into the app without having to
type it out (QR Codes, links, etc...).
Of course email itself isn't always the most secure channel, but for most businesses it is "secure enough".  Inventing a new delivery mechanism for more secure code delivery will likely cause more problems than it will solve.
Fortunately the worst-case scenario of a leaked application key is probably not too bad.  After all, someone actually purchased the key, so if an attacker manages to intercept and make use of a single-use case key, the original purchaser will likely be contacting you wondering, "Why isn't my key working?!".  Presuming they can provide proof-of-purchase it will be simple enough for you to revoke the app access for the current user and grant it to the new user.
This does create the risk that someone may use social engineering tactics to trick your staff into giving them someone else's subscription, and it also runs the risk of grumpy customers.  However, since the marginal cost for you sounds low (i.e. it is relatively cheap for you to give someone else access to the system), the loss is low even if someone occasionally ends up with a free subscription.
That was a bit of a ramble, but the most important part is just the thought process.  Security isn't binary.  It isn't secure/insecure.  It is only ever "secure enough".  The more effort you put into security measures the more likely you are to cause trouble for your legitimate customers, and at some point in time it is more cost effective to stop adding security layers and accept that an attacker may occasionally succeed in stealing a subscription or two.  As a result the trick isn't to make things secure, but rather secure enough.


Trouble understanding the explanation of "server certificate" message in RFC 5246?

A certificate chain is just a list of certificates each certifying the next so that you can start at some certificate you trust and conclude that the certificate for the server is valid.

Appropriate is a little difficult to explain in detail but if you look at sample certificates you will notice that the certificate includes things like

         X509v3 Key Usage: critical
             Digital Signature, Key Agreement
[...]

Signature Algorithm: sha256WithRSAEncryption

And appropriate means that you can only use the certificate for the given protocols and with the right key format and so on.


How to prevent users from copying their outlook pst file to an external disk or system

There is no reason to give your employee local admin rights on their computer, there is the principle of least privilege, please look it up and implement it. Giving everyone admin rights is a big no-no and can be even more dangerous when it comes to data leakage as successful attacks to your employee's their computer can now also result in exposure of your domain administrator account (due to cached credentials).

Furthermore data extraction is very hard to solve if the employee has rights to read the file in the first place. If you are allowed to read the file (which I imagine is important if you want to read email) then there is nothing you can do.

The only way to solve this is to set up a policy which explicitly disallows storing PST (or any other corporate data for  that matter) on non-company approved external media. When they leave the company they are required to return all media. If they don't do this after they leave the company and you can prove they actually took company secrets with them, you can sue them for corporate/industrial espionage.


Securing password in Java (config file and memory)

Your saving password is a duplicate question. If someone rings up your java application , it is better to get required password(s) by user or system admin who is responsible for the application run.

After you get the password . Never save it as a string. Because stings in Java are immutable and you do not have any control of those memory blocks (only JVM along with GC does). Try to store them in char[] in memory and do not use toString().

If you are dealing with a UI do not use methods such as getText() to retrieve a password. Use getPassword() method in JPasswordField as an exmaple.


How can a weak root password be compromised?

Short passwords are prone to easy shoulder surfing and brute force. If you are sure that all services which can be accessed remotely are off, feel free to keep short password. Also, make sure you are not storing any valuable, sensitive or confidential information on such system.

The point is to make the password cracking effort so hard that to compromise it will possibly take enough time and resource than the value of information stored on the system or till that time password will expire or is changed. However, given the power of cloud, now brute forcing something has become cheaper.

P.S.: I felt like putting the comments as answer.


How is "Touch Jacking" prevented on iOS, Android, and Win 10 - touch?

Here is a StackOverflow answer for Android:

The tapjacking attack has been blocked at the OS level since Android 4.0. For such devices, you do not need to do anything to prevent tapjacking attacks.
android:filterTouchesWhenObscured="true" helps on API Levels 9-13. It did not exist prior to that, and so that attribute will be ignored on older devices, if you are supporting those.

This newer article (English translation provided at bottom of link) states that setting these parameters on a window:

– LayoutParams.FLAG_NOT_FOCUSABLE (the window can’t receive the focus)
– LayoutParams.FLAG_NOT_TOUCHABLE (touch events will never be transmitted to this window)
– LayoutParams.FLAG_NOT_TOUCH_MODAL (touch
events will automatically be transmitted to the underlying activity)

will allow touchjacking. They claim they have tested this on Android 4.3 and 4.4. If this is correct (I've not tested it) then Android is susceptible to touchjacking. (If you test this, let me know in the comments what your results are and I'll add them to this answer.)


What is the best way to explain (a non-technical person) the risk of leaking version information?

Imagine a car robber specialized in stealing Toyota Prius models from 2010 to 2015. It will be pretty easy for him to identify this type of car, just by looking around and analyzing the model characteristics.

Now let's assume the car robber is blind and can only identify the car models by touching them. This would make it much harder for him, to spot the type of cars he is specialized in.

It's more likely that the car robber will identify and steal more cars of this type, in the first scenario.

In this metaphor:

The car robber is the attacker
The car model is the version information
The blind car robber is the blind attacker


Can a TCP connection be terminated by an attacker if SSL/TLS has been used to protect data in the TCP segment?

This is entirely doable, with the caveat being that you need to know the correct sequence number required by the target tcp stack. (so to be able to do it for all connections to a server, you have to be either on the server itself or a gateway to that server).

Note: the farther you are from the target stack, the more likely it is that you'll have timing issues with the injection. (presuming it's a packet injection and not a full mitm)

I also know from experience that such intercepts are swiftly broken with a small security update to the target stack :(

Rst and fin will be relatively closely guarded, it may be worth looking at just setting the tcp window size to zero instead? (just a thought, been a long time [a decade now!]  since I played with this stuff)

  ..but I would like to know HOW the communicating parties would know the connection is improperly terminated and why it is only interrupted.

The whole point of tcp it to provide reliable connections, if you kill the connection then the stack on each side knows. It's only interrupted because when the connection dies most systems will retry the connection, usually  without even telling the user.


Are Java (web-based) applications security threat?

Java exploitation: I think the most popular way to exploit systems with almost zero effort is with malicious Java applets. Used in conjunction with social engineering - almost every person instinctively clicks the 'Run applet' dialog. Even if you don't look at attacks involving SE, there are always exploits for the Java Browser Plugin freely available (IIRC, Oracle was phasing out the plugin. Don't remember the current status. Might be worth a look for you.)

tl;dr: Yes. All of these are possible attack vectors, either in combination with SE or through exploitation of unpatched systems or usin private exploits.

Just copied this over from your other Q.


Secure Memorable Passwords for Older Users

I am an advocate of the passphrase approach.  We all know longer passwords are harder for hash cracking attacks.  For several years I have advocated the use of a short sentence with typical capitalization and punctuation.  This produces inherent length and complexity, but might allow for easy guessing.  To make guessing harder, additional strength can be added with the use of a multi-digit number or an odd word, such as a nickname or foreign derivative.

The following are all strong passwords that are easy to remember and natural to type.

  My home was 7925.
  Bito loves little kids.
  Mum was born in 1918.

I advocate this approach for everyone, but it might be particularly helpful to older people.  Have them choose a fact from their youth, which is often easier for older people to remember than current facts.

Advantages:

Sentences or phrases are easy to remember.
Natural language includes punctuation and spaces which creates
complexity but is both easy to remember and easy to type.
Even the shortest of sentences is a long password.

Disadvantages:

Failing to include an odd word or multi-digit number can make the passphrase susceptible to brute force if the attacker assumes a sentence structure and uses a dictionary.
Typing a long passphrase without seeing what you are typing can be a
problem for some users.
Some systems do not allow the entire character set such as spaces
or punctuation.
Some systems limit password length.

Enough simple words in the passphrase will make it strong without additional complexity, BTW.  Consider: Using a very small English dictionary containing only 10,000 words.  Four words in a predictable pattern would have 10000^4=10^16 combinations, slightly more than a complex (chosen from 96 possible characters) 8 character password and each additional word adds more combinations than 2 characters in a complex password since 10000>96^2. So

  Dogs and cats are cute.

is stronger than a 10 character complex password even if the attacker knows that the passphrase is a simple sentence.

If you take the above and add in a odd word or multi-digit number, a four word phrase is a very strong password.

Including punctuation and capitalization mid-sentence significantly strengthens the passphrase, BTW.


Protecting a website from being kidnapped

If you are afraid an attacker might login to one of your accounts, it is best to ensure that all accounts have strong and unique passwords (e.g by using a password manager) and have 2 factor authentication enabled.
This way, if the attacker gets a hold of your password, he can not log in as he does not have the 2FA device.
As for your website, make sure you have proper working backups and test these periodically. Also ensure the backups are at safe locations which you control and can not be accessed by an attacker if he has hacked into your site/host/email.
Apart from protecting your accounts, also make sure the systems hosting your website (and the platform itself) are up-to-date.


Do Transient, Volatile Servers Require Antivirus Scanners?

You are asking yourselves the right questions but asking us the wrong one.

Security controls, like AV, are meant to address threats in order to reduce the impact to an acceptable level. You have identified the threats and the likely impact of those threats. Great! Now you need to see if signature-based AV addresses those threats and reduces impact to an acceptable level (or if the impact levels are already acceptable).

Can you address the propagation issue by changing the firewall/networking to block connections initiating from the front-facing servers? If so, then AV might not be necessary.

Could you gain the threat intel ("allowing staff to know about the presence of malware") by logging the non-transient servers? What does the data from the transient servers give you that your permanent servers do not? What's the likelihood that the transient servers will get infected uniquely? If you can get the data from other sources, then you might not need AV.

How do you update the AV database? Will you have to launch the server, update the database, then run a scheduled scan? Is this delay acceptable for the level of service you require? If the delay does not make sense for you, then you might want to use other mitigations.

But the underlying question is about the type of AV that you are assuming. You are assuming locally installed, signature-based AV, but there are other, more dynamic types that do not require database updates and only scans new or incoming data. Network-based, in-line, AV is possible, as well as IDS.

So the question you need to ask is if this one implementation meets your needs or if the risks can be met by other means.


Locking down web-based admin areas with personal SSL certificates

Here's some high level design things to plow through first.  There's a couple of ways to skin the cat, and how you set it up will impact the long term sustainability of this system.

Issuing and Managing Certificates:

So, you'll definitely need to issue each administrator his certificate.  As per usual, Microsoft plays well with Microsoft, so if you have your own CA set up already for issuing server SSL certificates (or domain controller certificates), then leveraging it might be an easy way to do this.  You'll need to think through:

How you get the certificates to admins
How admins store their certificate - for example, software certs are easy to create - and the private key gets stored in a file, but if you switch from machine to machine doing your job, how do you keep that private key safe?  on a USB?  USBs are easy to loose!  Imported into each browser on each system?  That's putting the key pair a lot of places.  Putting the certificates on smart cards or other hardware tokens is more expensive, but more secure.  But then you have to be sure that the admins have a smart card reader on each machine!  This stuff can really impact your security policy and should get figured out before you spend the time setting up the system.
How are admin certificates terminated?  The typical PKI process is revocation by the CA, but that assumes that your servers have a way to check certificate status via either CRL or OCSP.  IIS servers can do that (google "certificate status check" or "certificate status validation") but it almost certainly takes some configuration at both your CA and the server.  You may also want to stand up an OCSP server, if you haven't already.
how are certificates authenticated - you'll want to set up your IIS trust store to include the CA that is issuing your admin certificates.  This is a big reason to have a CA sign your certificates... if you do not, you need to configure every trust store to trust the self-signed end entity certificate and that is a maintenance nightmare.

How is privilege assigned?

A CA is usually used to issue a variety of certificates, only some of them are admin certificates.  How you design privilege assignments has a big impact on how well all this stuff works.  Here's some options:

make it a special quality of the issued certificate - for example, include the word "Administrator" in the Distinguished Name when you create and sign the Administrator certificate.  Look for that field when the admin logs in.  That may involve some custom code at the server.  Advantage - no extra centralized checking, Disadvantage - must have a way to consistently issue certificates, must revoke certificates when an admin leaves his position, must check certificate status.
configure privileges in Active Directory - as @M'vy's links say - there's ways to configure AD (or any LDAP server) to affiliate users (authenticated by certificates) with privileges (ie, being an admin) - this makes the setup eaiser to change - the user can have 1 cert, which he uses for admin stuff.  This privilege can be disconnected when the user is not an admin, or other criteria can be added via AD.  Means configuring your AD and your IIS server to check it.  Adds some complexity to user setup, as now the admin needs a cert AND a setup in the Active Directory server.
Statically configure at the server- keep a list of trusted admin certificates at the server, and check this list - that's the AD-free way listed on the links form @M'vy - that works fine for a small operation with no AD server, but it gets troublesome if you have to manage lots of servers, as each server needs an update every time an admin joins or leaves.

Any or all of these options will work - it's just a question of how frequently you change admins, how many servers you have to manage, and what you want the process to be.  Thinking all that out will save you much pain in the long run.

Here's some hit words for researching this stuff:
- to force user SSL based login with a digital certificate - "SSL client authentication", "client auth", "TLS client authentication/auth",
- for more configuration help - "cert(ificate) store", "trusted certs",
- for certificate status checking - "CRL check", "OCSP check", "cert status check", "cert verification/validation"
- for configuring privileges "role based access control", "privilege management",

And couple those with the software you are trying to configure.


Should a website limit characters that can be entered in its fields?

You shouldn't trust the client. Writing Javascript to stop characters being entered does not stop anyone from submitting them to your search.

Your search routine should remove characters it doesn't support, and when printing that back out, it should show what it actually accepted, not what was submitted.

For general purpose fields in a form, consider adding client-side validation for a more pleasant user experience; I'd rather know before I hit submit that you're not going to accept non-digits in the Phone Number field. But if I go around your Javascript checks and submit the form anyway, the back-end server should outright reject my invalid data; don't leave it to just the Javascript to sanitise input.

Also, while it's OK for most fields to accept anything the user can enter and repeat it back elsewhere, it must be escaped properly to prevent cross-site scripting (e.g. so the user can't set their name as <script src="...">). Some fields have additional concerns; for example, if you allow users to pick a unique username, Unicode equivalence could allow them to choose a unique encoding for their name that nonetheless appears identical to another user's name, allowing impersonation. Normalisation is not enough, because some characters look like other characters, still allowing impersonation. Read  Unicode security considerations for more on this.

Edit: Your colleague still has a point. The server-side does not live in isolation. If it accept inputs from a user and then shows some of those inputs to other users at a later time, it's not enough that the server-side is bulletproof against dodgy inputs. There's a whole category of security issues that happen client-side, because the server-side stored data exactly as-is and blindly handed it out to other clients (who are then attacked or fooled by it). Yes, server-side needs to restrict input characters, if they'll exploit or fool your users when handed back out again.

Recommended reading:

Unicode security FAQ
UTR #36: Unicode security considerations
UTS #39: Unicode security mechanisms (especially mixed-script detection)


Can Avast check my WI-FI password for strength?

Windows stores the Wi-Fi password in reversible format. A simple Google query for "how does Windows store Wi-Fi passwords" returns this article, which doesn't answer the question at all, but shows that Windows can at least display the original password.

That means that your Anti-Virus Software, which runs with elevated rights, can read out your Wi-Fi password and then run some checks against it.

For example, if your Wi-Fi password were zxcvbnm12345, it may detect the pattern behind and report it as weak.


The difference between DDoS attacks in the cloud computing and the traditional network infrastructure

I'm going to have to disagree with the other responders. There are a variety of differences that could theoretically matter. Note that none of these are guaranteed, just that they COULD.

Your adversary is probably also able to use the cloud and scale up the attack in a much more cost-effective manner.
Some advanced adversaries could attempt something along the lines of a side channel attack. For example, if you are known to operate in a specific region or datacenter, they could attempt to choke out your available resources.
As a DDOS victim in the cloud, you could end up experiencing the pain of the attack in two different ways: one, unavailability, but the second, increased cost of resources to handle the attack.
As a DDOS victim in the cloud, you may be able to better cope with an attempted DDOS, because you may have easier access to resources that can scale with the attack. For example, you could more easily scale up your infrastructure, you are likely to have greater bandwidth, and you can more easily add new security "devices" into your traffic flows.

On the other hand, detection varies little. There's no silver bullet, no automatic answer. It's an active area for academic research. However, because you don't typically don't operate the full stack of your network infrastructure in the cloud, the cloud service provider has an interest in helping you deal with these threats. They may provide tools, documentation, or support to a bit to help with detection. Consult your provider, but as one example, AWS has some suggestions on how to use its tools for DDOS mitigation here: https://aws.amazon.com/answers/networking/aws-ddos-attack-mitigation/


SRP protects only against a man in the middle sniffing the password. It does not protect against an active man-in-the-middle manipulating the transferred data.

Since active man-in-the-middle attacks in a local network are easy (ARP spoofing etc) anybody can make/manipulate the data and cause unwanted actions inside your securely authenticated but not tamper resistant connection.


Security problems with password-less SSH

There are three different scenarios here:

SSH password authentication. Here, the SSH server accepts a password. If the password's compromised, the system's compromised, regardless of where the attacker is.
Key authentication without security on the key file. Here, the system will only allow access if you present the appropriate key file. Shifts the problem, and gives you something less to remember, but means that you need to connect from or through one of your known hosts.
Key authentication with the keys secured with a passphrase. Here you enter the passphrase at the beginning of the session to unlock the key, and that's used for all subsequent authentication. An attacker needs both the key and your passphrase, but you do need to unlock it every time.

The security of 1 vs. 2 is debatable, they're both fundamentally 1-factor authentication (what you know and what you have, respectively), however, option 1 could theoretically be brute-forced on an internet-facing service. It secures against opportunistic attacks, but would stand up as much against something targeted. 3, on the other hand, is 2-factor, in that you have to have both parts of the equation to do anything. It increases the inconvenience (need to come from known host, and need to enter passphrase), but the security benefits are also significant.


Impossible removing JS:Downloader-FHB trj

Try clearing your magento caches. I had the same malware warning from Avast - after clearing my Magento caches, it went away - I suspect it was false positive of sorts.


Generally I would not suggest to strip the tags from an input. This won't work sometimes and it would still be possible to generate a valid XSS attack like in your example.
If you want to sanitize your input try using something like htmlspecialchars. This converts all your characters into HTML entities. So they are safe to display. If you want to allow HTML tags on your site I would suggest to use a html purifier so you can allow all tags you want. (Whitelist approach)

Regarding your question:
This would generate a valid XSS on your site without the three mentioned elements:

%253Cscript%253Ealert('XSS')%253C%252Fscript%253E

This type of attack is called double encoding if you want to search for it. If you want more information about XSS try using the cheatsheat from OWASP or Github.


If you are talking about file uploads to a server use various methods to check the filetype. The overhead is tiny. Magic numbers give you a more robust way to verify the filetype but can still be spoofed.

Never rely on file extension, this is the most trivial part to spoof.

If it were me, regardless of the risk to the system I would always:

verify file extension (the final extension and anything after a .) after sanitising the entire name
verify file size (within defined range)
Verify mime type
check magic numbers

All the above checks use a whitelist for verification.

I would also make sure the uploaded file gets moved to a secure directory (without exec permissions) and gets assigned a random filename.


How to create combinations of a password

The easy way i know is by using a python script to generate a password based on characters you remember.

for example

#!/usr/bin/python
import sys
import datetime
import os
import string, random
import itertools

info = '''

######################################################
                By ACT Group inc
######################################################

    Alex
    Clairic
    Thuli
    The Pukiisefu Family
    http://actgroupinc.com

    Note: We Feel Proud To Be Who We are
######################################################

#######################################################################
# High Speed Word list Generator : Compatible To All Operating Systems #
#######################################################################
+++The little indemise Rose that grew on concrete++++
######################################################
'''

print info
chrs = list('STACKOVERFLOWstackoverflow1234567890')
l=6
k = l
j= 10
n= j-1
for i in xrange(k,n):
  for xs in itertools.product(chrs, repeat=i):
    sys.stdout.write(''.join(xs)+ '\n')
    sys.stdout.flush()
print '''
\t***************************************************
\t*       Successfully created thanks for using     *
\t***************************************************

'''
raw_input("[*] Press Enter For Exit")

you just need to change the minimum and maximum length here

min

l=6

max

j= 10

Note: you need python 27 installed in your system plus you may modify the code to save the words in a txt file


VNC connection failed: Too many security failures

The information at this link suggests to me that it was an attempt at intrusion. To succeed in establishing a VNC session a legitimate user must wait. In practice waiting a few minutes is necessary before a successful VNC session is allowed once again. There is no need to re-establish the ssh tunnel.


is encoding the same as encryption for malware obfuscation?

Encoding and encrypting are not the same: encoding does not need a key, encrypting does. XOR is not encoding, is a very weak form of encryption. Base64 would be an example of encoding. Uuencode is another example.

The difference between XOR and AES is the difference between a wooden box with nails closing the door, and a bank safe. XOR can be trivially decrypted, but AES does not.

In this specific case of code obfuscation, XOR is astronomically faster than AES. It will defeat most signature-based IDS systems, and will not increase the resulting code too much. AES will create larger code and will be slower.

On both cases, any human inspector will be able to decrypt the contents, as you will have to supply the key to decrypt the code. Otherwise your program would not run at all.


How can I securely and conveniently move keys, certs and other short data across an air gap?

There is no "golden rule" on how to to move the data. The options you have listed give you a tradeoff between security and convenience. You should think of threat models and analyze your security needs.

When there is data on the machine I wanted to protect, I would use convenient means (like CD or throw-away usb sticks) to get data onto the machine, knowing that a malware could have been transported onto the machine, and very secure means (like QR code software or papers and typing) to get them back. Of course, if the data were really important, I'd ensure a good air-gap to defend against badbios-like (ultrasound) communication methods, or use very secure means for the other direction, to prevent malware to get onto the isolated machine.


You can store anonymous data regarding searches like search item, time made etc. Most websites employ a privacy policy that will outline what data they store (albeit vaguely) which will cover you to do what you outline but without one you must be very careful. To stay the right side of the law.


How to verify TLS renegotiation DoS vulnerability? (CVE-2021-3449)

This seems like a good potential test package that you can use https://github.com/terorie/cve-2021-3449


Are there any standard practices for protecting against malicious links being entered in a public form?

Before the email is sent, you can grab all URLs with a regexp, and then submit them to Googles Safe Browsing API to check if they are known to be malicious. If so, just don't send the email or include a warning.


What firewall settings on a Macintosh are the most restrictive, while still permitting casual internet use?

Go buy Little Snitch http://www.obdev.at/products/littlesnitch/index.html for $30.

  Little Snitch informs you whenever a program attempts to establish an outgoing Internet connection. You can then choose to allow or deny this connection, or define a rule how to handle similar, future connection attempts. This reliably prevents private data from being sent out without your knowledge. Little Snitch runs inconspicuously in the background and it can also detect network related activity of viruses, trojans and other malware

And in your System Preferences | Security | Firewall, ensure your Firewall is on, select Advanced and checkmark "Block all incoming connections".

For ultra-paranoid surfing, buy VMware Fusion (http://www.vmware.com/products/fusion/), install your OS of choice in a virtual machine and use that for surfing.  After a round of browsing in the dark, you can hit revert to restore your virtual machine to its virgin state.  You could also build several virtual machines and use the appropriate one for the tasks at hand (e.g. virtual system A for when you do banking activities, virtual system X for when you do dastardly activities).


How does Network Discovery OFF protect my computer?

This setting turns off browsing answers.

Browsing is a protocol on windows networks where one computer send a broadcast to a local network "who else is there ?" and other computers answer.

Think about opening the 'Network' or 'Network Neighborhood' icon. That is what it does. It sends that broadcast and shows computers that are "discoverable".
If your discover is off, you won't appear on their list.


Scan all possible files on server (Brute force Filenames)

Check out DirBuster where you can feed wordlists and it'll try to brute force file and directory names.

Nikto also checks for commonly used folder and file names on a web server.

It is not possible to check every file and folder name, however running the above tools will give you a decent amount of enumeration.


How do I know which padding was used in a cipher suite?

Padding in TLS is almost the same as the PKCS#7 padding, but with some subtle differences.

When using CBC encryption, in TLS, things go the following way:

The MAC is computed over the plaintext, and appended to the plaintext. In the case of TLS_RSA_WITH_AES_128_CBC_SHA, that's HMAC/SHA-1, so 20 extra bytes.
What will be encrypted is the concatenation of the plaintext, the MAC and the padding. The total length must be a multiple of the block cipher size, i.e. 16 in the case of AES. The padding consists in appending n+1 bytes, such that 0 ≤ n ≤ 255. So there is at least 1 extra byte, at most 256, all have the same value, and that value is one less than the padding length.

(In true PKCS#7 padding, there would be n+1 bytes who all have value n+1, not n.)
Upon decryption, the contents of the padding bytes MUST be verified, as well as the MAC. Doing so securely is hard to do but if you are writing an inspection tool, then you are the attacker, and thus can afford to do things most insecurely.

In the older SSL 3.0 version, only the last padding byte had to have value n, the other bytes being random (and this is a weakness in the protocol). Conversely, in SSL 3.0, the total padding length was not allowed to exceed the block cipher length, whereas in TLS it can be longer (up to 256 bytes), as long as the total padded message length is a multiple of the block length.

For an inspection tool, the simplest implementation method would be to decrypt with padding "none", and then inspect and remove the padding and the MAC with explicit code that you write yourself. There is no "standard" padding method implemented in Java that would match the variant used in TLS.

If you are interested in decrypting SSL/TLS handshake, it might be a good idea to first write your own SSL/TLS library -- not for production use (these things are very hard to get right with regards to side-channel attacks), but more to gain experience in the fine details of the protocol. When your own library succeeds at completing a handshake, you know that you got all of them properly. Also, the code elements will be reusable for your inspection tool. Thus, writing your own library is a good pedagogical investment (as long as you remember the condition: not for production use !).

You may want to read this answer as an introduction to the protocol.


Why does an encrypted message sometimes end in "=="

The = signs relate to the length of the string being encoded in Base64. Essentially, in probably the most common form of Base64, = is used as a padding character to ensure that the last block can be decoded properly.

Base64 is not encryption - there is no hiding going on in it - but is often used to allow for binary data to be sent in text only form. All the characters used in Base64 will paste correctly, and can be entered using a keyboard with no modifier keys beyond shift.


Testing Basic Authentication with ncrack

The path option needs to be used in conjunction with the -g (global) or -m (module-specific) option, like so:

ncrack -m http -U users -P adobe25 http://webserver_ip -g path=/~alice/secret/

Please note, however, that Ncrack is not maintained. You would probably be better off using Nmap's http-brute script. From the Ncrack web page:

  Deprecation Notice: Ncrack was written as a "Google Summer of Code" Project in 2009. While it is useful for some purposes, it is unfinished, alpha quality software and isn't currently maintained. Instead, we generally recommend the brute force scripts included as part of Nmap's Scripting Engine (NSE).

EDIT: In spring of 2016, Ncrack's primary author Ithilgore began work again on Ncrack. It is again under active development on Github.


How server knows about the client_write_key to decrypt the client message?

Look at RFC 5246 Section 6.3. On both sides, bytes are generated using the PRF from the same arguments, so the generated bytes are the same. Those generated bytes are used the following way: The first "mac_key_length" bytes (e.g. 20 bytes) are the client's MAC key and the next "mac_key_length" are the server's. Then the next "enc_key_length" (e.g. 16 bytes) are the client's cipher (e.g. AEs) key and the next are the server's, etc.

Each sides knows whether it's the client or the server, so they choose the right MAC/key/IV when reading and the other MAC/key/IV when writing.


Malicious packet that attacks packet sniffers?

You have to know what software the administrators are using to sniff the packets, additionally you have to know a vulnerability that is capable of crashing the application.

If these requirements apply, the answer to your question is yes.

For reference, take a look at past wireshark vulnerabilitys:
https://www.cvedetails.com/vulnerability-list/vendor_id-4861/cvssscoremin-9/cvssscoremax-/Wireshark.html


Sorry to burst your bubble, but here's actually only one mode of Yubikey that REALLY makes sense for PW managers in a complete sense and that is the Smartcard mode, but there is basically no passowrd manager that actually uses it.

Online Password Managers often go with Yubi-OTP due to it's sheer compatibility only requiring a USB slot and basic keyboard drivers (and a keyboard layout that doesnt screw modhex), but some are also going to U2F simply because

It's more secure to there not being any shared secrets (Yubi-OTP uses shared secrets with Yubico when used in their cloud setup or with the provider in a custom setup)
you cannot identify the specific key used. you know, the first 12 or so characters of a Yubi-OTP are the serial number in modhex (factory default) or something the user chose when customizing it).

this allows the backend to look up the correct keys to decrypt the actual OTP data, for U2F on the other hand, while you generally are not wrong about the KDF(domain,secret) thing for generating the key, there's a LITTLE bit more to consider.

There actually is a third value used in there. a random nonce generated at registration which is part of the "key handle" which is needed for authentication and is why even if you use single factor U2F you still need a way to know who you are authenticating (like a user name) to provide the key handles along with the challenge.

Offline Password managers often go with the HMAC road which is literally just HMAC(data, secret), depending on the details of your password manager they do it in one of 2 ways:

just use the result from HMAC(some static value,secret) as part of the decryption key, which does work but is obviously bad since one capture leads to its compromise.
what Keechallenge is doing: they store the secret and use that to pre-generate the next result to use in the decryption process while storing the challenge for that result in the open to obviously issue that challenge during the next open.

both methods are not ideal since seeing just one decryption breaks this for the complete lifetime of the database except maybe if a rotation (of the challenge for 1, of the secret for 2) is done every now and then.

considering how yubikeys work on PW-DBs we can basically see how U2F can work in pw databases.

online obviously as data valve, "you ain't getting the db unless you bring the U2F"
offline as snakeoil
offline in a similar manner to yubikey HMAC, we keep the keyhandle open to issue it and actually use the public key not as an actual public key but just as content to generate our symmetric encryption key.

if this sounds crazy to you, let me assure you, it is crazy but it's not much different than using HMAC mode for encryption.

the only REAL way to encrypt stuff is Smartcard and/or PGP mode with rotating symmetric keys on each save, so the private key is actually needed to decrypt the database and that private key being ONLY in the yubikey.


Your suggestion sounds like the prudent one. But here are some bullet points for the conversation.

Bullet points of the CONs of using wifi cameras:

Confidentiality - even if the cameras use 802.11i or other appropriate encryption, the images can be captured by an attacker who monitors the wireless transmissions and cracks the encryption.
Integrity - Depending on how the camera manages the image after transmission (does it save local and require the user to delete it? Does the camera delete it after transmission?) there is a possibility the image may get corrupted in transit, as it could with ANY transfer. In this scenario, if the image has already been deleted from the camera then you have lost the data. It's an unlikely scenario with several specific conditions, but it IS one of the points of the InfoSec triad (Confidentiality, Availability, Integrity)
Cost - I am pretty certain the cost of WiFi enabled cameras is much higher than media-readers (USB SD readers are probably < $10 Amazon.) Extra SD cards are cheap too, if you don't get ridiculously large ones.

Some PROs for going with WiFi cameras:

Convenience - even with SD media readers, the users have to go back to the workstation and swap out media. If the business campus is very large, this could be an inconvenience or a real waste of time.
"Gadget Fun" - Oooh, shiny! New! Gimme fun toys! =) Everyone likes getting new toys/gadgets/tools to play with, right?


Why is S/MIME (instead of PGP) recommended for such an scenario?

That's because of "enforced". PGP uses a Web of Trust which is, by nature, decentralized. To enforce things, you need some hierarchical structure with a central point of decision, which X.509 provides (in this case, through the "self-signed CA at headquarters). In the PGP model, each user is the center of his own world and cannot be dictated his trust.


Selinux: How to log/monitor all accesses to a file?

Yes, SELinux can be used to log accesses, not just denied accesses. See this message for some details on how to do it. This documentation may also be useful.


Prevent organization's code from being leaked or stolen

Your developers will, by necessity, have access to the code. Implementing some system that, say, only allows them to edit code in a special application that doesn't allow copying into the system clipboard will annoy them, and they'll circumvent it, if only to be less annoyed.

The standard alternative approach is a legal one: employees sign contracts, and if there's a sniff that they've taken proprietary information elsewhere, your corporate lawyers get in contact and scare the pants off them. This will be cheaper and much more effective than a technical solution.


Pseudonymisation - Should e-mail addresses in the application be masked?

GDPR requires you to protect the personally identifiable information that you store, and to limit access to it. As a lot of people will have their name in their email address, one should regard emails as personally identifiable.

You should limit the access to email addresses, so that it is only viewed when needed, by as few people as possible, taking into account the time and cost needed to implement these safeguards.

Article 25 states:

  Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of
  processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the
  processing, the controller shall, both at the time of the determination of the means for processing and at the time of the
  processing itself, implement appropriate technical and organisational measures, such as pseudonymisation, which are
  designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the
  necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of
  data subjects.
  The controller shall implement appropriate technical and organisational measures for ensuring that, by default,
  only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies
  to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility.
  In particular, such measures shall ensure that by default personal data are not made accessible without the individual's
  intervention to an indefinite number of natural persons.

http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L:2016:119:FULL

Based on this, I would argue that yes, you should mask the email addresses of the users so that they are only visible to staff when needed. If the staff logs into the system for the sole purpose of viewing the email addresses, I would argue that you don't have to make any changes. But if the staff uses this system all the time, giving them access to this information also when not needed, you might have to make some changes.


Need advice on automated virtual pentesting lab configurations

You can develop some challenges yourself. I suggest having a look at all the challenges which all have already been published on ctftime. Construct your own flaws within a new environment. This will make sure that they can't just download the solution from the internet.

Also just my 2 cents, but I think you should allow other tools than you allow now. Automated exploiting is easy mode. You should make 2 environments, one where they are allowed to use Nessus, Nexpose,... and one where they can't.
I would encourage them to create their own tools, as this is commonly done in reality as well. A good pentester can use and build tools himself when needed.

I see little tools in your kit for webexploiting (Zap or Burp (if you can't afford it go with Zap) for instance). In reality Web application assessments are on of the most sold A&P services at the moment.


Is storing a client's folder structure a security risk?

This doesn't jump out at me as a security risk.  Sensitive data is stored in databases all the time.  If your database is somehow compromised, I suspect that client directory structures getting out would be pretty low on your list of concerns.