Database logs have multiple "Logon Login failed for user" from different IPs

Firstly, IPs can be spoofed - but for TCP-based connections that actually log in, they can't. Or they can only with unbelievably high cost.

Secondly, is there a reason your database access is not restricted on a lower level via a packet filter for example? Usually, you would only grant connection capabilities to IP ranges that do have reason to connect to the database in the first place (instances of web applications, for example).

Thirdly, this looks like a scanning tool that tries to maybe tries to fingerprint the database. The huge delta of two seconds between the attempts may be for the dbms to recuperate and have a timing attack revealing version information - or just to not trigger an IDS. Yet, every IDS I know would/should pick up on that anyway.

So all in all: You should restrict access on Layer 3 or 4 and have that potential risk of brute forcing bots trying to login go away.


Good ways to prevent spammers from registering

The simplest way is to add a hidden input to your form, and refuse to submit the form is that input is filled.

Another efficient way to do this is to generate a token cookie, store its value inside a hidden input, and compare both of form submission. Since most spambot can't handle JS, it won't work for them.


Does SAML 2.0 define how to pass username and password for authentication?

SAML does not support sending a username and password to the identity provider from the service provider. There is an AuthnRequest (authentication request) that may be sent from the SP, that starts a session at the SP, and tells the IdP, "hey, I don't know who this user is - authenticate them, and then respond back to this location, with the user's identity, and pass me this RelayState to let me know what session to associate the user with."

What you're asking about (a service provider passing a username/password directly to the identity provider and retrieving an assertion) is a function of an STS, or Security Token Service. A very common STS implementation is WS-Trust, which does commonly "wrap" a SAML Assertion token in the response.


What is the vulnerability in my PHP code?

Free doesn't go far, but you can try running the following yourself:

The community edition of netsparker:  http://www.mavitunasecurity.com/communityedition/
skipfish:  http://code.google.com/p/skipfish/
And if you want to dig deeper & you're willing to spend a little time learning how to wield it, you can download and fire up Burp:  http://www.portswigger.net/burp/

The black box scanners listed above would likely catch the more obvious vulnerabilities (especially if you manually "crawl" your app to ensure the scanners test everything - each tool supports manual crawls, for example, https://netsparker.zendesk.com/entries/351851-manual-crawl-proxy-mode)

Also, you need to do validation on the client AND server:

  OWASP:  "Performing validation in client side code, generally JavaScript, provides no protection for server-side code. An attacker can simply disable JavaScript, use telnet, or use a security testing proxy such as WebScarab to bypass the client side validation."


Under most circumstances, if you connect to the site by HTTPS, and you're sure that the URL is correct (i.e., you're not connecting to a phishing site, like gm4il.com instead of gmail.com), and your browser is not showing you any certificate warnings, then most likely it's safe to login to the site using your password.  If you use a password manager, all the better, as this offers the added protection of detecting phishing sites.
However, this answer would not be complete without adding the caveat of fake SSL certificates.  There have been cases where CA's have been breached, and attackers were able to get CA-signed certificates for popular sites such as Gmail.com, etc.  In this case, all of the above indicators would seem to indicate that everything is copacetic, yet an attacker on the network between your browser and the site would be able to intercept your password.  See What are the risks of a Certificate Authority hack for 'the average user'? for more information.  Fortunately, these cases are rare, but it would be remiss to not mention these cases.


What is the difference between concealment and secrecy in context of confidentiality?

Concealment is hiding something or someone. What is concealed may or may not be protected. Perhaps it is merely hidden. Concealment is something done to prevent disclosure, usually a single action.

Sergeant Jones wants to conceal his truck from aircraft, so he hides it in a garage. But if he had wanted to protect it too, he would have put in a bunker. Concealment means hiding. We rarely speak of a level of concealment.

Now he has a plaintext message. He is going to conceal it inside a photo and send it to the friendly local militia. If he had wanted to protect that message, he would have encrypted it.

Secrecy is a practice, the state of holding secrets, between people. Everything that Sergeant Jones does is done in a climate of secrecy vis-a-vis a specific threat or threats. We can then speak of levels of secrecy. Secrecy expresses overall security needs--the big picture of relationships, trust, privacy, and disclosure.


There is no singular IP Traceback implementation, although researchers have proposed many solutions in the past.

If you look at the Wikipedia article under the "Router based approach" section, you will find a few proposed methods of fingerprinting a packet.

Here's an article from CISCO that touches on techniques routers can perform to prevent IP spoofing.

I'm not aware of any router that has a turnkey solution that performs IP Traceback outside of your own network though. There isn't a standard protocol to request an IP Traceback.


Reading locally-stored emails sent encrypted

Thunderbird prior to the completely re-written version 78 provided encrypted GPG/PGP email support via the Enigmail plugin.
Sending encrypted email used both your public key and the recipient(s) public key(s). This was easy to see simply by selecting the sent email. You would be prompted to enter your own Private Key to decrypt the sent mail, or you could look at the message source and see the -----BEGIN PGP MESSAGE----- content.
Thunderbird 78 is a complete re-write and no longer uses Enigmail or GPG. It now uses a subset of OpenPGP.
It still includes both your public key and the recipient(s) public key(s) but it's less easy to verify, you'd have to open the email via an editor outside of Thunderbird 78 to see that the sent copy is indeed encrypted.
So what's going on with Thunderbird 78 and the OP's question, "Does Thunderbird store an unencrypted copy of the emails anywhere?"
No it doesn't store unencrypted email, it stores your Private Key and auto opens everything!
Now it gets even fuzzier.
The New Thunderbird developers will tell you that the stored Private Key is encrypted, and it is, but it's automatically accessible via another key stored in the Thunderbird database, in the clear.
The next level of fuzz is that the official line here is that if you use a master password then the database is protected by the master password. This is true, but this means all of your private keys are protected by only the same master password.
The net result is that Thunderbird 78 automatically opens all your encrypted mail because it has all your PGP secret passwords. The developers insist that this is for search and sort convenience and is what users desire.
By contrast, Enigmail never writes private passwords to disk, they exist only in your head and in RAM while being actively used. Additionally opening one key does not open other keys.
Interlink is a Thunderbird XUL based fork. It supports Enigmail and Lightning plugins. You can even drop your current Thunderbird profile (Pre-78) into Interlink and be instantly converted over. It runs on Linux and Windows.


Encrypt data, still able to do text search

No, this is not possible with secure encryption. The reason is really simple.

What you do requires that you are able to create the cypher text ξ(λ) of a small piece of plain text λ and then can find that cypher text everywhere where λ occurs in a bigger piece of plain text Λ.

When people do crypto, they attempt to reach so-called protection goals. One of them usually is or from the ones in place it follows that an outside observer cannot figure out whether the same piece of text occurs twice in the same message or even whether 2 messages stem from the same plain text. Therefore, ξ(Λ) is not guaranteed to contain ξ(λ) and finding ξ(λ) in ξ(Λ) doesn't tell you anything because it can show up anywhere.


Attack vectors for brute-forcing website passwords

How else could a brute-force password attack be carried out?

You've covered both bases, and that's really about it.  Either repeatedly submit to whatever web frontend is available, or manage to get a copy of the hashes by cracking the database server, abusing the web software, what have you.

Web frontend cracking is usually more an issue of smart force than brute force, and as a result, it works better than you would assume.  For example, given a web site which had a company directory - first, last, and extension - for about 100 people, I was able to "brute force" 30% of the accounts simply by throwing together some algorithmic guesses with that data.  And the authentication site was Microsoft Exchange, so I stayed below the threshold of NSA recommended lockouts and was fine.  (In fact, this was a pen test and I verified before testing to ensure I wouldn't lock out users, but it was an easy guess to make correctly). Even with the slow rate of guessing, I was done in under a day.


Is it possible to recover a Diskcryptor volume password?

Sadly, no.

The whole point of the system's security is that there is no way to retrieve it other than brute forcing, and at that password length the entire key space will take a considerable amount longer than your life to brute force!

Unless you wrote it down or stored it elsewhere, you'll need to assume whatever was in that encrypted space is gone.


Are passwordless SSH logins more secure?

Key based login is considered much more secure than password based logins when looking from the perspective of a brute-force attempt to gain access from a third party system: The chances to crack a key are effectively zero, while bad passwords are all too common.

From the perspective of a compromised client system (your workstation), there won't be a difference because if the attackers can get your private key and/or hijack a session, they could likely also install some kind of key logger, rendering the perceived advantage of passwords useless.


This really isn't useful or effective, it only specifically protects against shellshock (and with the amount of publicity it received I am fairly confident that a similar attack will not happen again. )

I should also point out that your whitelist would not actually protect a system which is effected by shellshock either.


Phone Applications having SSL/TLS enabled behind the scenes?

Short answer for your question is yes, most major (and official) social networking apps use encrypted connections.
However, if you are interested, there are ways you can find out for yourself by setting up a proxy server that allows you to forward traffic through that system and then analyze the data. There are however, some tools to do this:
1- There is an Androguard extension called MalloDroid that

facilitates static code analysis of Android applications.

Specific details are as follows:

Analyze the networking API calls, and extract valid HTTP(S) URLs from
the decompiled apps
Check the validity of the SSL certificates of all extracted HTTPS
hosts.
Identify apps containing API calls that differ from Android's default
SSL usage, e.g., contain non-default trust managers, SSL socket
factories or hostname verifiers with permissive verification
strategies.

2- ZAP by Zscaler is a

web-based tool designed to streamline the capture and analysis of
HTTP(S) traffic from mobile applications. ZAP is capable of analyzing
traffic from both iOS and Android applications.

ZAP checks the following:

Authentication: Username/password sent in clear text or using weak
encoding methods.
Device Metadata Leakage: Data that can identify an individual device,
such as the Unique Device Identifier (UDID).
Personally Identifiable Information Leakage: Data that can identify
an individual user, such as an email address, phone number or mailing
address.
Exposed content: Communication with third parties such as advertising
or analytics sites.

Sources:

http://www.techrepublic.com/blog/it-security/android-apps-and-ssl-wheres-the-padlock/
http://zap.zscaler.com/about.php
https://code.google.com/p/androguard/#Description


Is it safe to share your `gitconfig`'s `user.signingkey` value with the world?

Is it safe to share your gitconfig's user.signingkey value with the world?

Yes, that is safe.

The signingkey value is your GPG key ID (the lower 64 bits of the fingerprint) which is derived from your public key and does not carry any secret information. Therefore you can publish it to the same extent you would publish your public key. (Instead of the shorter key ID, you could also use the full fingerprint for the signingkey value.)


TrueCrypt seems to offer the ability to use a key file with its encryption.

***As a major disclaimer TrueCrypt technically is no longer supported and may be insecure.

Here is a guide that you can use to add a keyfile to that encryption. You could store a key file on a USB and use that in addition to a password. There might be a more automated way to do this via detection of a USB and search for a filename but this is pretty close to what you want I think.


What does a Let's Encrypt (or other DV) certificate prove?

DV certificates only validate that the certificate request for a given domain came from someone who has control over that domain. It validates nothing else. An attacker who can hijack your site's nameservers or otherwise take control of the domain's DNS settings will be able to get a DV certificate issued for them.

Avoiding this requires using a different (and more expensive) certificate, specifically OV (Organization Validation) or EV (Extended Validation). An OV certificate involves the CA verifying that you exist as a legal entity and have permission to run that domain, such as verifying that example.com is owned by Example Ltd. An EV certificate additionally verifies your physical presence, checks that you alone have exclusive control of of the domain, and ensures that you have legal authority to request a certificate. Naturally, these certificates are more expensive as their issuance cannot be automated like DV certs.


Which information of a VMware image can be monitored from the host?

Which information (e.g. https traffic) can be monitored from the host? Is it safe to browse on a virtual machine that uses the host device's network adapter (regarding privacy)?

The host has full access to peek at the memory of the VM. It can read any secret crypto keys from the memory of the VM, and trivially decrypt all TLS traffic if it wants to. It can interecept all communication at will, and inject traffic into the networking stack of the VM.
You can't use a VM to protect against a rogue host.


I don't think you can do this with firewalls, at the networking layer. When you connect someone with TeamViewer, you don't do it directly. TeamViewer users connect each other by using a third party server in the middle.

You can see the answer of kobaltz for the question How exactly does a remote program like Team Viewer work?

  When you run TeamViewer, you are assigned an ID on their broker server. You make a connection to a Teamviewer ID, and TeamViewer passes the connection down through the TeamViewer client's established tunnel to the destination and you then you are prompted for password and then the connection establishes afterwards.

To achieve your goal, you should use TeamViewer's way. I think this article from TeamViewer is what are you looking for:  How can I restrict access for TeamViewer connections to my computer?

  You can also restrict access to your computer in different ways. Depending on how you want to restrict access and to what extent, choose one of the following options:

  To completely prevent any access with ID and password, exit TeamViewer in the taskbar.
  Any incoming or outgoing connections are no longer possible.
  To restrict access to ordained devices, use the Black- or Whitelist in the TeamViewer full version. Deny incoming connections for specific TeamViewer IDs or only allow connections for defined TeamViewer-IDs.
  To restrict features for incoming connections, use the access control for incoming connections. Choose between Full access, Confirm all, viewing access or deny any incoming remote control connection.
  To deny connections from outside your network, only allow incoming LAN connections.


Implement a passcode to authenticate app users

You don't need to do anything special here.

Storing the token locally in app storage is sufficient.

It is worth considering periodic token expiry requiring more complete authentication via SMS token, email token, or a username and password.


When PHP retrieves the GET parameter with $name = $_GET['name'], it performs an implicit URL decoding. PHP doesn't require you to decode an URL parameter yourself.

These both result in the exact same value for $name:

http://yourapp/?name=<script>alert(1);</script>
http://yourapp/?name=%3Cscript%3Ealert%281%29%3C%2fscript%3E

So even if < looks like %3c in your URL, it will be stored as a literal < in $name. In consequence, the str_replace() part correctly recognizes < and > and filters these characters out, thereby preventing XSS.

The vulnerable part is the explicit urldecode() at the end.

If you provide the URL http://yourapp/?name=%253c, then variable $name will literally contain%3c (that's three characters) and the str_replace() functions will ignore it because neither of %, 3, c looks like an angle bracket. Then, in the end, urldecode() unnecessarily performs another decoding and turns the sequence %3c into a literal < after it has already passed the replace filter.

If it's still a bit unclear to you, replace $name = $_GET['name'] with this:

$name = urldecode('%253Cscript%253Ealert%25281%2529%253C%252fscript%253E')

You will see that this has the same effect as providing the string as the URL parameter and it shows that two urldecodes are redundant.


As indicated on the IPv6 roadmap of the Tor project, tor has had support for exit nodes contacting destinations over IPv6 since 2.4.8-alpha. The closest stable release I could find that followed is 2.4.19 from the end of 2013. I don't know exactly which nodes need to support it for a connection to be established over IPv6, but by now, every node in your chain should have at least that version. So all you're seeing is your exit node contacting whatismyip.com over IPv6, and whatismyip answering with the exit node's IPv6 address (the address format seems to confirm this is a manually chosen address as it ends in 0:0:0:3).

If you still have the exact IP, you can check it was indeed an exit node on that day using exonerator.

By the way, IPv6 implementations do not necessarily leak the MAC address by default thanks to RFC4941, which, in addition to a MAC address based IP, assigns a randomly chosen temporary address on every interface, which changes regularly and is used by default for outgoing connections. On Linux this can be controlled using net.ipv6.conf.all.use_tempaddr
net.ipv6.conf.default.use_tempaddr. Many distributions don't enable it by default, saying it can cause problems for unaware users, and I'm having trouble finding out what the default value is for whonix, but as a privacy oriented distro, I would hope it is activated... Of course, manually assigned IPv6 addresses also don't have to leak the Mac address.


TLS version intolerance (SSL/TLS) - Command Line - Ubuntu

If you can install python and scapy you can use the  tolerantls command-line utility to check for TLS version intolerance.

Usage is quite straight-forward, e.g.:

$ tolerantls.py --host example.com
  [*] Testing TLS version intolerance against example.com:443
  [+] Server is not intolerant - it downgraded the client request and proposed to use TLS_1_2


Typically yes, but it depends on how the web server is configured.

If someone can run a PHP script on a server, he can execute commands, get file listings and include other files. However, this is still bound by normal user rights. On most systems all PHP files are executed as the "apache" or "httpd" user, which would need read access to all these files. This means that any PHP script can be read from any other PHP script.

However, it is possible to secure this. It is even possible to run two subdomains on two totally different webservers, which would make access between servers impossible.


Accidentally came across the source code for some malware, what to do?

I'm afraid your compiled binary will differ a lot from the actual malware that can be found in the wild. Different compilers and command-line flags will produce completely different binaries, and the malware binary may be further optimized/obfuscated using additional tools or even manually.

Submitting them your compiled binary is likely to be counter-productive and will only waste everyone's time. Instead, if you can't directly submit the source code file (because their form expects a binary, etc), try to get in touch with a human and give them the source.


Automatically search Metasploit for useable exploits based on vulnerabilties in the database

This functionality is mainly what can be expected by most vulnerability scanners. For one but Nexpose and Nessus automatically say if a Metasploit exploit is available and what name it is.

There is a plugin available here on github, which could do what you want given some modification in regards to openVAS integration. This plugin does auto-exploitation against a vulnerability scanner's imported DB.


Do I ultimately have to hold a key in my head?

In human terms, this "final key" often takes the form of a password.  The password is used to gain access to the place where the "real key" is stored.

In the computer security world, we use cryptographic algorithms to perform the security operations.  But some of these algorithms can't just use passwords as keys, because they require specialized large numbers to make the math work.  Since we humans aren't typically capable of remembering 256 digit cryptographic keys, we need to use storage devices to hold them.  And because we don't want just anyone who gets ahold of that storage device to have a copy of the keys, we usually protect these secret keys by encrypting them.

But now we're back to the same problem:  how do we encrypt these secret keys if we still can't remember a key?  Instead of remembering a key, we remember a password, and use an algorithm called a Key Derivation Function to turn our password into a cryptographic key.  This key is then used to decrypt the actual secret key needed to access the sensitive data.

In the physical world, this is similar to placing your car keys in a safe.  You'd have to know the combination to the safe in order to get the car keys, the combination lock turns your combination (your password) into mechanical position of pins and disks (the physical manifestation of the key required to throw the bolt,) then you could open the safe and get the car keys. Once you have the car keys, you can unlock the car and drive away.

And for very high security keys, such as the master keys for a debit card network, or the root certificate keys for a Certificate Authority, it is not uncommon to keep the keys or a password printed on a piece of paper and locked in a safe. Only the data owner knows the combination.  Another choice with cryptography is to split the key into three or more parts, requiring three people to get together to reassemble the key.


If you have to write an information security guide for non technical users, what would you cover?

I would recommend that people read Consumer Report's Guide to Online Security.  It is excellent and covers a lot of what people need to know.

Beyond that, here are a few more suggestions:

User behavior. I would have some recommendations for how they behave online:

Practice good password hygiene.  I recommend that people pick two very strong passwords: one for your email account, and another for your banking and financial stuff.  Don't re-use those passwords anywhere else.  To select a random password, a good approach is to pick a phrase -- a sequence of four or more words -- that no one else is likely to guess or choose.  Anyone who breaks into your email account may be able to gain access to all your other accounts, so it is important to protect that one carefully.  And the need for a strong password for banking is obvious.

As long as you trust the folks you live with, it is fine to write these passwords down.  Writing the passwords down will make you feel comfortable choosing long and strong passwords, so it is generally a good thing (contrary to what you might hear from others).

For other sites, I suggest you pick other throwaway passwords.  They usually don't need to be especially strong.  It is fine to write them down, and I encourage it.
Use your browser password manager.  Take advantage of your browser's password manager, so you don't have to memorize your passwords.  When it asks whether it should remember your password, say yes.  Once you know that you can count on your browser to remember your password for you, it will free you up to choose hard-to-guess passwords.
Be careful where you enter your password. Bookmark security-sensitive sites, like your bank and your webmail provider.  When you want to log onto them, click on the bookmark then enter the password.

You want to avoid a situation where you are on some other site, click on a link, and then enter your banking or email password into the resulting page.  That's unsafe, so get out of the habit of doing that.  Similarly, avoid clicking on a link in your email and then entering your password into the resulting site.  If you get an email from your bank and want to log onto your bank account, click on the bookmark to your bank and then enter your password.

This is the equivalent of how to protect yourself offline.  There's a common scam where someone calls you up, pretends to be your bank, and asks for your bank details.  To avoid falling for that scam, all you need to remember is "don't call me, I'll call you": don't provide your banking details unless you called the bank yourself.  If your bank calls you and wants personal information, hang up, then call the bank's phone number on your bank card.  That's a good idea offline -- and it's a good idea when on the Internet, too.  When using your browser, follow the same practice.
When browsing, look up. When you are browsing the web, if you ever have any questions about what web site you are currently interacting with, look up at your browser's address bar.  You can identify the domain name of the site (the part that says, for instance, www.google.com) near the left side of the address bar.  In many browsers, it will be highlighted.  If you are considering entering in personal information and have any questions about who will be receiving the personal information, the address bar will tell you the answer.
Never download software from unfamiliar sites. Avoid downloading software from anywhere except the most trusted sites (otherwise you can get hit by malicious software).  If you're browsing the web and some random web page says you need additional software to view the cool videos or something, don't do it.

System administration. I would start with some recommendations for setting up their system:

Enable automatic updates. This is the best way to ensure you are always running the best, patched version of all software.
Enable automatic backups. Set up a backup system to automatically and routinely backup your system, without your involvement.  This is one of the best ways to ensure you can recover from a compromise.  Security is more than just prevention; it is also about enabling rapid and reliable recovery from compromise.
Choose a secure browser. I would recommend Chrome.  Firefox can also be good.  If you use Firefox, install HTTPS Everywhere, to ensure you use HTTPS (SSL/TLS) on every site that supports it, and I recommend AdBlock Plus to many people.
If using Windows, install free antivirus. The number-one user error I see on Windows is that people think they have antivirus software running because it came with their system.  What they might not realize is that the pre-loaded software is a trial version whose license expires after a while (a year or less); once it expires, they're not protected any longer.  Therefore, I recommend that people install antivirus.  To save some money, I usually recommend a free antivirus checker: Avast seems decent, and some recommend Avira.

Alternatively, you could just buy a Mac.  It's more expensive, and it isn't a silver bullet, but it tends to mean you don't have to worry about anti-virus software.  (All of the other comments about user behavior still apply regardless of platform, though.)


How can we show our end-users that we are trusted by a bank?

If it is possible in your scenario, you might want to "multi-host" your service, under a subdomain of their domain.
E.g. newService1.bank1.com, and have them provide you with their own HTTPS certificate.

This creates an environment where you not only trusted, but it is THEIR service - at least from the perspective of the user, especially if you provide whitelabel branding, their logo, etc.

Note that in this case, you should isolate the bank from other tenants' service - on the backend as much as is feasible, but especially from the user's PoV. E.g. don't make the user re-select which is his bank, or any other bank-defined configuration, you need to function as if you ARE the bank's system. Or if you send out emails to users, these should be identified as the bank's newservice.

(P.S. this also can give you some great marketing tools, onboarding options, and easier to close the sale with many organizations... )


Can a Time-based One-time Password (TOTP) key be decoded from generated values?

TOTP is explicitly designed to resist this.

TOTP is based off of HMAC-based One-time Password (HOTP), which works as follows:

Two parties share a randomly generated key, k, generally called the "shared secret". This key must remain private.
Both parties maintain a counter value, c, that is incremented whenever authentication is performed.
Authentication is performed by computing HMAC(c, k) where HMAC is some HMAC function such as HMAC-SHA256. The resulting hash value is then processed to extract some number of bits, which can then be transformed into a number of decimal digits in order to produce an authentication code. This extraction and transformation is generally called "truncation" in this context.
The party that needs to be authenticated (e.g. a user) sends the digits to the other party (e.g. a server), who computes the the same hash value and performs truncation and compares it to the digits provided. If they match then the user is authenticated.

Since both sides know the same key and (theoretically) maintain the same counter, they can always authenticate together. Usually the party doing the authentication adds in some leeway for counter desync, e.g. by computing all the possible codes from c to c + 5 an accepting any that match. This results in a security reduction but allows for some counter desynchronisation between parties.

TOTP modifies this scheme so that c is replaced with ct, which is a time-based value. The value of ct is calculated as ct = (t - t0) / tx, where t is the current time (e.g. in Unix epoch seconds), t0 is the time at which the token was created, and tx is an interval time such as 30 seconds. Effectively what this results in is a ct value that increments every 30 seconds. As long as both parties' clocks are roughly synchronised and are not skewed (they may have different clock times set, but t0 compensates for that as it is set independently by each party) this results in both clients producing the same TOTP outputs at the same time.

Breaking this scheme by only knowing what digits were given out (even if millions of codes were known) is not feasible as it would require a full key recover attack against the HMAC hash algorithm (e.g. HMAC-SHA1 or HMAC-SHA256) which has not yet been done. For proper HOTP and TOTP implementations you are protected against key recovery and even counter recovery.

However, not all implementations use a proper HMAC function as the keyed PRF. Some HOTP implementations, such as those in radio-operated garage openers, utilise a proprietary PRF or even something like CRC32 in order to generate the hash value before truncation. These can usually be broken by recovering a few values becuase the search space is so small.


What is an "appropriate" request size limit for a web service?

This depends on what the webservice is doing.

I'd re-write this OWASP line to: "Verify that all input is limited to a size appropriate for the service".

So if you control the input you can set the size based on that, if the service is accepting something varying size for example images or files, then you'll have to pick a limit which you are happy with and makes sense for the application. There's no point setting it at 1gb if the service is expecting images taken with a smartphone for example.


Best Practices for Storing Digital Certificate

The first approach is better. Your concerns are misplaced. In the example you give, the verification should succeed. The data was indeed signed by the certificate it claims to have been signed by.

If I sign some document, then it's very important that it only appear to have my signature if it hasn't been tampered with. But if you can tamper with it but then have to put your signature on it, that's fine. You did sign its contents. I didn't, but it doesn't appear to have my signature. So that's fine.

You still must decide what that signature means of course after you decide it's basically valid. But that should be considered a separate step.

The design should be based on the fundamental security principle that an untrusted attacker cannot obtain the private key corresponding to the public key authorized by any certificate the system would accept as valid. Generally, it will be based on the common name in the certificate and the identity of the authority who signed it.

You can safely store the data, certificate, and signature together. This will allow you to validate the data and signature. The important thing is that you properly decide what that validation means by looking at the certificate.


USB modem software installs autorun.inf parser, are there any risks?

Autorun used to be enabled by default in Windows XP, and would execute any file referenced by autorun.inf when a storage drive is plugged in. It used to be really easy to execute malware from an USB drive, just reference it in the autorun file and let Windows do the rest.

It was disabled in Windows Vista and later for obvious reasons, and yet this software reimplements its functionality, most likely as a cheap workaround so they don't have to print an information leaflet telling users to run the software manually.

Checking USB IDs is not sufficient as a rogue device can enumerate as any device, including the original modem's, and yet present a rogue file. Checking for a signature is risky as well, as you don't know how well the associated private key is protected (I wouldn't entrust anyone thinking this software is a good idea with a private key). There may also be vulnerabilities in the code that checks the device itself.

Finally we don't know how this is implemented. If this run as a service under the system user, then this would not only run potentially untrusted code from USBs but also run it as SYSTEM. Worse, this could be implemented as a device driver which means malicious code could be run with even higher privileges.

This device is a bad idea altogether - throw it in the bin and get a mobile<->Wi-FI bridge, those don't require any shady drivers and appear just like any untrusted host on the network, something you can defend against with a firewall.


Best secure way to transfer virus from server to different location for investigation

The "industry standard" of transferring sensitive samples is to encrypt the sample. Then you can use any preferred way of transferring files like email. This also prevents antivirus products from detecting and possibly destroying the sample. An accessible and secure way of encrypting is to use a file archiver and set a password. Note that some email gateway antivirus products will try to unpack the archive by using a short password list.


Is the following authentication solution safe or am I missing something?

I'm not sure this should be an answer, but I have too much to type for a comment...

What you are suggesting looks OK to me, with some assumptions:

The shared secret is good - no 'test123' etc.
The crypto you use is good. No ROT13 ;)
The usernames are case-sensitive, sounds obvious but I can imagine registering user abc and gaining access to user aBc's info

As a principal I think it works. The only thing I can think of is if a user is somehow able to register an account on server A that already exists on server B, but I'm sure you've thought of that.

Obviously if you have other security issues (vulns on either of the servers, the usual web attacks etc.) then all bets are off.


Knowing the building blocks for whatever you are trying to secure is always a place to start. If you want to secure networks, then knowing TCP/IP is a great place to start.
TCP/IP is an old standard. The foundational books are old. The one's you've linked are in my own library, and are considered to be some of the core texts on the subject. But, you need to choose the books and the material that are right for you. Pick one and try it out.
People change careers all the time, even late in life. I know guy who started off in chemical engineering, who is now in his late 30's and is jumping into IT Sec. Age doesn't mean anything, what you can do matters.


Are there modules to harden Symfony 2 sessions?

What you are describing is a session hijack.  This is not something that a session handler can defend against.   Foolish attempts to check the user-agent are trivial to bypass.  Limiting the session to an ip address will make your application inaccessible to legitimate users behind a load balance, while still allowing access to attackers on the same local network.  Web applications prevent session hijacking by fixing vulnerabilities such as Cross-Site Scripting,  Session Fixation,  and OWASP a9 vulnerabilities. (Don't forget about CSRF aka "Session Riding").

You can enable browser-based security features to protect the cookie with the following PHP configuration:

session.cookie_httponly=1
session.cookie_secure=1
session.use_only_cookies=1


Are there any vulnerabilities in TLS 1.0 that can NOT be avoided by proper implementation?

I think that if:

Both sides implement empty record protocol packets or the 1/n-1 split[1] to mitigate the BEAST attack
Both sides send bad_record_mac alert rather than the decryption_failed alert in case of CBC padding error

Then TLS 1.0 is as secure as TLS 1.1. Then, if you also add:

Both sides implement correct timing safe checking of MAC for MAC-then-encrypt, including lucky13, which is so difficult basically everyone [2][3] made a bad bug while trying to implement it and one of the best TLS implementers in the world punted on implementing it for the Golang TLS stack because it's too hard [4][5].

you have a system in which the TLS CBC ciphersuites are secure. Of course, the recommendation is to switch to AEAD.

1 - https://bugzilla.mozilla.org/show_bug.cgi?id=665814#c59

2 - https://blog.cloudflare.com/yet-another-padding-oracle-in-openssl-cbc-ciphersuites/

3 - https://blogs.aws.amazon.com/security/post/TxLZP6HNAYWBQ6/s2n-and-Lucky-13

4 - https://github.com/golang/go/issues/7418#issuecomment-66091828

5 - https://www.imperialviolet.org/2013/02/04/luckythirteen.html


Using phpinfo() to get httponly cookies?

First of all, I assume that you are the owner of the website disclosing the phpinfo, and you ask this for academic purposes.

To achieve what you said, I would do the following :

Create an invisible iframe (0px x 0px)
Store cookies in var x by parsing the iframe content through contentDocument getter/setter
Create an invisible <img/> (0px x 0px) with src set to your sniffer URL
Concat x to the querystring in the src attribute
Add your <img/> to the <body>
(At this point, the browser will try to load the <img/> even if its not a picture)
Read server GET logs on your sniffer

Edit: I did not see that this thread was a 4 years old one ...


What are the disadvantages of logging someone in on register?

You are introducing a user enumeration flaw into your system.

That is, any attacker can find out if bob@example.com is a user on your system by completing the registration process.

This is useful to an attacker for two reasons:

As per the article linked above

  As an attacker if I can use your login or forgotten password page to narrow my list from 10000 targets to 1000 targets, I will.

In a phishing campaign, the attacker knows exactly who to send their emails to.

There is also a privacy issue, especially if your site is something sensitive like Ashley Madison.

If the above is a concern to you, you can mitigate by requiring the user to acknowledge the activation email first. See this answer.

If not, then as you are not allowing them to access sensitive content or actions, there is little extra risk. If you were, then you could simply have a flag in the database: EmailConfirmed = 1 or 0, which will let your system know whether they can trust that the email address is genuine.

Also, not verifying users can be an annoyance when an email address is mistyped or purposely entered that of another person, in that the account gets squatted and the real user cannot then register their own account.

The real user of the account can sometimes regain control by completing the password reset process, although their account will then be tainted by whatever the previous occupier has setup. Again, this depends on the system but if there are sensitive settings such as extra recovery email addresses or access keys, or other active sessions, then there should be a way for users to reset their account to a fresh state after any squatting incident.

The other thing that may make reset tricky is if two factor authentication is employed. Any password reset by the real email address owner would be hindered due to lack of the second factor being available. In this case, it would be much easier to validate email address at point of signup instead as things can get complicated otherwise.


What personal traits and characteristics do you look for in a IT Security pro?

Employee security clearance is a major issue for organisations, and even more so in positions of sensitivity such as admin, root or super-user roles. My usual thumb, is to assume that these roles can do much more damage than a normal user so heavily protect your organisation from them. Traits may be the wrong word though - as many traits of highly skilled professionals are the same as highly skilled criminals.

In some countries this is easier than others, but basic security clearances include credit and criminal checks (if an individual is heavily in debt they become more amenable to persuasion from criminal elements, and a criminal history should rule out individuals for sensitive roles, especially if it was a crime associated with IT fraud.) Known associates should also be researched.

For highly sensitive roles, regular rechecks may be required. And an awareness of your employees behaviour could be a value add! Salaries should also be reviewed - underpaid roles are a straightforward target for bribery and corruption.

This doesn't really change if the individuals has unique skills, as underlying the roles should be an infrastructure which prevents misuse, for example restricting administrative rights to only those required should be a given. For most platforms, root or Administrator access is not required, so where relevant a Power User or lower should be used, and root should be restricted to emergency occasions - where it requires input from two individuals:

an example:

Database admins often demand full superuser rights, but this is almost never needed. There are many types of admin role which can be assigned as appropriate, and root can be a break-glass role which requires retrieval of a password from a safe, or from two individuals each holding half.

To summarise - yes, IT gurus are essential but dangerous; protect yourself from them with technical and procedural controls, research their background and use their skills to add value.


Get Device names of surrounding WIFI devices without authentication

No  this is not possible. Generally the names you’re talking about come from NETBIOS, bonjour, UPnP, or some other broadcast protocol. These, however, only broadcast within their own networks so unless the device connects and then you capture a beacon you’re out of luck. You could potentially build something that was an SSID of ‘attwifi’ which deauths clients after they broadcast their name if you really wanted to collect device names.


What can manufactures of hardware do to prevent attacks on the firmware?

One solution is to require all firmware to be signed and have the device check the signature before writing that firmware image to its memory; my current laptop has an option to enable this in its BIOS (the option is permanent - if I enable it now I can't disable it anymore, that's why I didn't enable it).

There are many drawbacks however :

induces a false sense of security, as we don't know how the manufacturer protects the private key used for signing and I don't expect them to admit their failure and send a nice "Sorry the firmware key leaked" email to each customer; also even if the key didn't leak, the NSA and other evil agencies may still have stolen it and no one would know.
making custom firmware is impossible - while I'm fine with the fact that they're for-profit companies and their firmware is closed source, I am definitely not fine that they prevent me from installing whatever I want on my own devices I paid money for, for some so-called "security" even though the NSA already stole the key from them (I remember installing a custom BIOS on my old Thinkpad because the original one had a wireless card PCI ID whitelist preventing me from changing their outdated 802.11g for a 11n model, something impossible with firmware signature checks in place).

Another, better solution is to require physical intervention (a press of a hardware button on the device itself) to allow firmware to be installed, which doesn't have the above drawbacks; the firmware authenticity check is to be done by the user and he is free to install whatever he wants. Whether the user wants to install firmware, he presses the button and the device allows one firmware install before locking itself again (or timing out after a minute if nothing was installed).

The only drawback with that option is each device would have its own hardware button, on a typical desktop computer there's the BIOS/EFI (which will often update everything else embedded on the board - NIC, "fake" RAID controller, etc), possibly the third-party video card's option ROM (also called video BIOS), third-party RAID controller or NIC, storage drives, etc.

While everything on the board could be wired to a single button, all third party hardware would have its own button, sometimes hard to press due to the hardware being inside the computer's case. This isn't too problematic as users incapable of opening a computer case usually don't update firmware anyway due to the "risk" (it's minimal but creating bootable DOS disks feels scary) and complexity.

A theoretical solution would be to require all commonly used ports (SATA, PCIe, etc) to include a dedicated "firmware flash" line that would be hard-wired to the board's main firmware flash button.


Is TrueCrypt safe enough to store clear-text-passwords?

That's as good as encryption is gonna get.  TrueCrypt is a well-vetted, respected piece of software for disk encryption.  There are no guarantees in life, but TrueCrypt is about as good as it gets today.

The primary remaining risk is not that someone is going to find a cryptanalytic weakness in TrueCrypt and break TrueCrypt's encryption algorithms.  Rather, the main remaining risks are:

That you will choose a poor passphrase for TrueCrypt.  Defense: Choose a long and strong passphrase for TrueCrypt.
That one of the machines you use has malware on it.  If you type your TrueCrypt passphrase into any machine that is infected with malware, you no longer have any reason to expect you are safe.  So, do you trust your machines are likely free of malware?

(More layers of encryption won't do anything against these risks.)

The short answer is: if you think your machines are clean of malware, this approach is likely to be safe enough.

P.S. If you lose the drive, and you don't have any backups, you're going to be out of luck.  So, keep a backup of the file somewhere else: maybe a printout that you keep in a secure location, maybe another copy of the drive, also encrypted, or maybe something else entirely.


Interoperability of openssl smime, rsautl & dgst

The difference between rsautl and dgst is explained here:
https://stackoverflow.com/questions/9951559/difference-between-openssl-rsautl-and-dgst

Regarding smime, it's saving result in email friendly format, the one which can be appended to email messages.

So all these 3 commands are not inter-operable because each command does something else.


Is it more or less secure when an entity shares it's security procedures?

In general, the consensuses within the security community is that disclosing security practices (aka, transparency) leads to improved security. Transparency has many benefits:

It gives you motivation to do security right. Sometimes doing the right thing for security is annoying or costly, and having no one to account to makes it tempting to not do it the right way. When everyone can see what you're doing, you have more motivation to do things correctly.
It means that more people can scrutinize what you're doing wrong. An open system can be analyzed by many more people who can suggest improvements. In general it is assumed that motivated attackers will find these weaknesses anyway, so the more honest people that can see the weaknesses the more likely it is that the weaknesses will be reported in a timely manner. The alternative is living in bliss and only knowing about a problem once the attacker has exploited it.
It means that you are confident in your design. Security is hard to do well, and many people hide their security practices because their practices would appear bad. Making it open shows that you are not only comfortable with them, but that you are willing to fix problems that arise.
It allows others to learn from the things you do right or wrong. This has little direct benefit for you, but it allows others to benefit.

That said, transparency is really only beneficial if you plan to respond to security problems. If you aren't planning on it, transparency can cause problems because you make the attackers work less hard to find vulnerabilities.

PCI is a public standard that a lot of people conform to, so it's unlikely that very many of the details related to your implementation will be very unique. It's possible your boss doesn't think that information about proposed PCI compliance would be harmful.


Burp+Genymotion: Not all traffic from app in Emulator proxied through Burp

There's 3 probable cases:

Android application setting another proxy on its http requests hence bypassing system proxy and burpsuite.
Application setting its http handlers to ignore android proxy settings and connect directly to the destination.
Application is using non-http protocol.

If 1 or 2 is the case, you'll have to use wireshark or reverse engineering techniques to find the domains that the application is interacting with, lets say xxx.com and yyy.org.
You then have to use adb shell to modify /etc/hosts ,let's assume burp's listening on 10.0.3.2, add the following lines to /etc/hosts:

10.0.3.2 xxx.com
10.0.3.2 yyy.org

You might need to remount system partition as "rw" to be able to change /etc/hosts:

mount -o rw,remount,rw /system

Then under burp proxy, set it to listen on port 80 and 443, then under settings for each of these listeners enable "invisible proxy" option, if there's http/https traffic sent by the application you will now be able to see/intercept them in burp.

We are making the device resolve application's domain names to our burpsuite's address. We can also change device's DNS to our controlled server which returns burp's address for all requests. This solution falls short if the application directly connects to IP addresses rather than domain names. If the application is using non-http protocols burpsuite won't be able to catch the traffic.


In some situation can be dangerous to echo command (e.g. rm -rf *) using a script?

As mentioned here:

  You could pipe your command into a shell so it gets executed:

  Or you could pass it as an argument to a shell:

  Or you could use the bash built-in eval:

Even if your script contains several lines, including echo "rm -rf", it would be trivial to cat it and extract that line, and then apply the above mentioned tricks to wipe everything.


Is putting an authentication tokens inside the HTML body safe?

Not the best. Defeats the whole reason behind httponly cookies. Namely any JavaScript can read the token and exfiltrate it. It adds a lot of complexity to your threat model.

Instead use the cookie and host the api and static page from the same domain name.

If you cannot redesign the API, then proxy requests from the client -> your frontend -> the api.

When the client hits https://your_frontend/api/* -> you first check their cookie, then you read the API token from your server, append it to the API headers, and proxy the request to the API server.


For the relationships between OpenSSL and FIPS 140-2, read this documentation.

The OpenSSL FIPS Object Module is a specific subset of OpenSSL, API-compatible with OpenSSL, and provided as source code. That module has gone through the long and painful administrative process of obtaining a FIPS 140-2 validation. It has achieved the "overall level: 1" (see the validation certificate).

The intent of FIPS 140-2 validation is to show, basically, that some level of "seriousness" was applied during the development. Validation cannot prove that there is no bug or vulnerability, but it can show that the developers applied proper methodologies which, hopefully, should avoid bugs and make the software conform to a specific set of target properties.

Now, there are some caveats:

In practice, the OpenSSL developers applied the same development methodologies for both the FIPS module, and "plain" OpenSSL. Both versions share a lot of code; the FIPS module is actually a subset of the normal library version. For the same functionalities, the plain OpenSSL should be no less secure than the FIPS module. (For functionalities which the plain OpenSSL offers but not the FIPS module, anything goes).
The FIPS module is validated only insofar as you use it absolutely unchanged. If you modify the slightest character in the source code, you are no longer covered by the FIPS validation.

The second point, in particular, implies that if a bug is found in "normal OpenSSL", and a bugfix is published, then that bugfix is not immediately imported into the FIPS module, because that would void its FIPSness. Therefore, it can be argued that the plain OpenSSL is in fact more secure than the FIPS module, since it is fixed much more quickly when holes are uncovered.

Summary: if you do not target some sort of conformance to FIPS 140-2, use the normal OpenSSL.


Should I reply to an email saying that I requested online access to a website?

It's likely legitimate - there's little gain in getting you to reply to a spam email. All it reveals is that your email address is active, which isn't a particularly valuable piece of information.

To be safe, what you can do is instead of replying to the email, find the contact information for the alleged sender via a web search, then forward the email to that email address. This will ensure that the email goes to a legitimate party. If you want to hit the middle of the road, you can find out a legitimate email address for them, and check that the email that you received has the same domain - eg they will both end in @example.com. If they do, then replying to the original email will go to them. Be aware that unicode lookalike characters are a real risk with this approach.


django-python3-ldap Does TLS Encrypt AD Passwords When Site is Hosted on http

If you setup the web server with HTTP only the password will not be protected. The setting of LDAP_AUTH_USE_TLS=True only covers the protection of the connection between the server side part of your web application and the LDAP server and does not help in protecting the connection between browser and web server.


System Hardening: Outsource to Security Expert or have Sys Admin do it?

What generally is done is to hire a security expert who creates a custom webserver hardening standard and baseline, adjusted to your company's needs. The standard defines which security controls should be in place, technology independant. Then the baseline can be technology specific, e.g. IIS or Apache,...

The baseline can be implemented by your system administrators, however, you should perform routine audits (can be done by the expert or other independant auditor) on the machines (once every year or half year) to confirm that the baseline is implemented correctly. Any defects to the baseline should be documented during the audit and presented back to the administrators and a a response on why the particular webserver didn't adhere to the baseline.


Can the device on the other end of a socket change without me knowing?

If this is a simple UDP or TCP socket all the information which are needed to take over the connection are visible in plain on any system in the middle. This means a man in the middle could fully take over the connection after it was established or even just put itself inside the connection and forward modified data to the original peer.

But if the application protocol has an internal state which can not be derived by the attacker from interceptable information then such a take over is not possible. This is for example true if SSL/TLS is used on top of TCP. In this case a man in the middle attack is no longer practical. But an attacker on the endpoint itself might for example inject its own code into a running application and thus control what data get transferred over the socket.

Man in the middle attacks are also not possible if the attacker can not sniff the plain UDP or TCP connection. This can be achieved by protecting the communication path at lower layers, for example with IPSec or other VPN technologies. But attacks at the endpoint itself are still possible in these cases too.


Is a prepaid SIM-card with 3G data anonymous?

many of the large mobile (internet) providers use huge NAT to manage internet access for their customers.  I recently was doing a forensic job and was surprised to learn that some don't keep any track of their IP assignments to "handsets" against time/source port.

So if a web connected resource is trying to establish who was using an IP address associated with a 3G connected device (direct; no VPN etc) then some telecoms provider will not be able to satisfy their request simply because they don't store the information - at all.

This is interesting information for those that wish to have privacy online but what is not clear is exactly which mobile providers do this.  Also, with the 3G provider that I dealt with (through a legal team) some of their devices/customers are monitored for IP address assignment and others aren't - e.g. the prepay USB 3G dongles are monitored, but prepay handsets aren't.

good for privacy - but a bit frustrating when you're an investigator!


Playing a shared video file or viewing a pdf file in "incognito/private mode"

Incognito / private modes are simply a way to get a temporary browsing session that starts with no cookies or history. Incognito / private modes (with some variations on implementation) will still allow new cookies to be created and saved, temporary files to be created (including things like PDFs opened in the browser) and the history for that browsing session to be available (in some form) - all of this happens on-disk. Once the session is closed (all incognito / private browser tabs) then all those things associated with the session get deleted.

Important to note here that files that are downloaded, as opposed to viewing in the browser, will persist beyond the incognito / private session.

Note that if using extensions or plugins then those may not respect the intended ephemeral nature of the session and may save data permanently somewhere.

So yes, anything that utilizes temporary data in a standard browsing session will do the same in an incognito / private session, but that data will be deleted when the session is ended.


There's not really a solution to it. Deauth packets are part of the protocol. If you're using WPA, someone can send deauth packets. One method of mitigation would preparing for wireless location. If you notice an attack, you can quickly triangulate and neutralize the source.

This question also deals more specifically with making sure you aren't vulnerable to other issues that can come from a deauth.


If a remote user types in a password in a LogMeIn session, can the controlled computer extract the characters?

It is theoretically possible to intercept any event on a computer that you have full rights on. In practice, the difficulty of intercepting will depend on the way the input comes into your computer and whether the software handling that input actively seeks to prevent that interception (think about gaming anti-cheating software).

A password typed and sent via a browser can be intercepted by using a web proxy. If SSL is in use then you have to trust the fake certificates generated by the proxy. You can use Burp Free Edition and install it's certificate.

For passwords inputted into simple software, you could also find the password in memory and write a program that reads it from memory. To find the exact memory address, you first have to input a test pattern and find it in memory. An easier way is to dump all the memory, parse the strings and look for your test pattern and remember the strings in the vicinity. Then dump the memory with the real password and look between the strings you noted at the previous step. In Linux it is easier because you have /proc/<pid>/mem for the memory content of any process and the strings command is built-in.


Is this invalid HTTP_HOST header part of an exploit?

To expand on the answer provided by @Swashbuckler, CVE-2017-8295 specifically relates to WordPress password resets with the HOST HTTP header set.

When WordPress sends out password reset emails, they set the From/Return-Path to the value of $_SERVER['SERVER_NAME'] (in PHP). This value is set by some web servers (e.g. Apache) based on the HOST HTTP header.

This means that attackers can make WordPress send out emails that have From/Return-Path set to an email address of their choosing. If the email is bounced or responded to, it will happen to this malicious email address and - if the original email was attached - the attacker will then have access to the password reset link.

Actually abusing the exploit requires two factors to happen: the web server must read the hostname from the HOST header, and the email must be bounced or replied to. The former can be fixed by the server admin (if using Apache, by setting UseCanonicalName On), the latter requires the attacker to somehow block the victim's mail server (e.g. by DoS'ing it) or for the victim to reply to the email.

As pointed out by @TerrorBite, the attackers aren't actually targeting the password reset links, but only using the bug to exploit a bug in the PHP mail() function. See his answer below.


Length of AES "plain text" when decrypted with wrong key

The length of the decrypted bytes should always be a multiplicative of the block size, no matter if a correct key is used or not.
There might of course be a situation where the decryption with the wrong key results in an output that looks like it uses a valid padding and by removing the padding the length is unequal to the original length. But that certainly isn't the usual case.


Can we detect risk signals or potential vulnerabilities in git meta-data?

... but this seems to be a way of detecting vulnerabilities which already have been spotted by other developers.

This is the wrong interpretation of what he did. He tried to create a machine learning model which predicts the risk from git meta data. This model is trained with supervised learning where the label in the training data (vulnerability or not) is derived from associating a commit with a later bugfix or not in the same place. The model is then applied to previously unseen commits in the hope to estimate the risk of a bug. Unfortunately no results are shown of how good this model performs in practice.
Apart from this there are some patterns associated with the meta data to be expected, like: Changes very late in the day have probably a higher risk since the developer might be exhausted already from all the work. Some developers tend to introduce more problems than others since they are less experienced. Small commit message for large commits might be associated with more vulnerabilities too. Commits in areas where lots of vulnerabilities occur are more risky than others. Etc.
But directly detecting a vulnerability from the meta data is the wrong expectation. At most one can decide which  commit  have a higher risk than others in order to more thoroughly review the more risky commits.


Bluehost Wordpress Site hacked multiple times FTP MMprobe php file

The best scenario would be to take the last backup of the website and just re-create it fresh on a new server. You should contact their support for help. There could possibly be rootkits and other hidden stuff inside your application files, which could take a lot of time to weed out.

To prevent FTP attacks

use latest FTP service version
use strong username, password
setup fail2ban on FTP to prevent brute-force attacks


I doubt we'll get to know the exact details of how they were able to put the malicious JavaScript on newegg.com. For that to happen, newegg.com would likely need to provide the public with undisclosed information about their private infrastructure.
Speaking in general terms, the answer is that... something was insecure on their server or within their software. There are virtually unlimited possibilities of how this may have happened.
The following detail is interesting:

A key date in the Magecart attacks against Newegg come from the
registration data of the neweggstats.com domain

This implies that the forensics team at Volexity were not able to determine when the attack began using data found on newegg.com's server. For instance, files that had been touched may have had their timestamps reverted to their pre-modified dates. Their estimate of when the compromise began is based on a domain registration date... but maybe the attacker had been using a less convincing domain for a long time before deciding to switch to neweggstats.com.
A few common possibilities are below.
SQL Injection
An attacker may be able to discover enough about your database schema to learn that the contents of a given table/column are inserted into every page without sanitization. The attacker may then discover an SQL Injection point and be able to INSERT a script tag into the given table/column. The software would then happily include the attacker's malicious JavaScript on the page.
Phishing for admin credentials
The administrative portion of the website may openly allow script tags to be included in the site's layout in some way. This could include general template editing (ability to make changes to the website's HTML using an editor) or it could be something like an admin tool that allows you to upload payment images for the checkout pages (technically, this is the same as the first example).
The software might even allow an admin to simply upload a JavaScript file that would automatically be included on the website.
Providing value
Any third party JavaScript that you include on your website has the ability to be malicious. One could simply advertise a service for advanced ecommerce analytics to get their malicious code included on your site. Then the site owner would do the hard work for you.
Unsecured image uploads
Images can contain executable code. Some sites allow users to upload photos with their product reviews. If newegg.com allowed this, but did not sanitize the images, then an attacker would be able to get their executable code on the server easily. Once on the server, the attacker would need to cause the server to "run" the image as code. This can be done if your server is misconfigured or if your software has a security hole that would allow the image to be included as code. The malicious executable would then run with the same permissions as the webserver (or worse). At that time the software could append code to an already included JavaScript file on the server.
Summary
Writing software and making it secure are very different tasks. Sometimes a company puts emphasis on adding features because the folks that run the company are primarily interested in their profits. The idea that labor should be invested in securing their software never even crosses their minds until after a breach has taken place.
Often the employees who might be responsible for securing their software are inexperienced, underpaid, overworked, or inherit insecure systems from previous employees. When no one has the job of securing your server / software, vulnerabilities find their way in.
The method(s) an attacker may use to compromise a site is usually multi-faceted and may not be completely understood even after the compromise is discovered. Hiring a forensics company can be helpful, but their abilities may be limited due to the server's configuration (for instance, logs may only be stored for a short period of time).


Do security questions subvert passwords?

The manner in which security questions are used by a site, determines whether they undermine the supposedly stronger authentication mechanism (of using good passwords).

Typically, systems that allow access to users after they've answered a security question, are weaker than systems that would communicate a (temporary) password to the user via a (different and secure) channel. The previous statement conveys a best practice, and certain systems need not implement all of it; some systems would provide a new password (which need not be changed by a user), and there are other systems that would communicate the password via an insecure channel.

Filling a security question with random characters is not necessarily a good approach (although it is better than having a smaller answer with low entropy), for it would make it difficult to remember, resulting in a potential lock-out scenario (from where this is often no point of recovery). It should be remembered that security questions are often not changed periodically unlike passwords. The answer therefore depends on how well the answer is protected (both by the user and the system), how public the answer actually is, and how frequently can the question (and answer) be changed.

Reading this related StackOverflow question is recommended, for the answers discuss out-of-band communication, amongst other issues like the potential lock-out scenario.


How does client authentication work when using a TLS Proxy?

Since the TLS connection will be terminated by the TLS proxy the authentication of the client via client certificates will be terminated there too. Since the TLS proxy does not have the private key of the client it will not be able to use the original certificate of the client when connecting with TLS to the final server.

The only way to pass the clients original certificate or information about it are thus outside of TLS, for example by inserting some fields into the HTTP request header as described here for HAproxy. The server or web application then needs to check these fields at the application level instead of relying on client certificate validation at the TLS level.


Should different web apps running on VDS each have their own user account?

Yes.  These accounts let you limit the amount of damage that an app vulnerability that allows shell access can do.

Let's consider the things you might want to proactively protect:

Static files that are served with same-origin privileges like JavaScript.  These should not be writable by any app account since they need only be read and only by the user account for the particular app that serves them.
Log files.  These need to be written by a single app account, but not read.
Configuration files and scripts.  Some may be shared but they should not be writable by any app account, and unless you have good reason, make per-app config files only readable by that app user.

If your users are tied to database privileges, then any per-app tables should only be modifiable by that app's user, and schema change authority should be reserved to administrators.


Finding the type of SSL certificate with cURL

You can only make assumptions based on the contents of the Organization field (DV certificate will either have the domain or "Persona Not Validated" in the organization name field)  or in the policy identifier if it is there.  Certificate issuers do not follow any unified scheme to differentiate OV vs DV.  So, with cURL, you will have to do write your own checks of these fields to get a best guess.  More information in this possible duplicate question: How does an end user differentiate between OV and DV certificates?


To get a remote shell on the target system, usually there are two common scenarios:
- reverse shell
- bind shell
Based on your post, I'm assuming that you have a web shell already, and that you have been able to upload reverse shell code to the target. Furthermore I interpret your comments the way that your reverse shell has not been able to connect back to your local listener because of the target's outbound firewall rules. Have you tried various ports?

A bind shell will not work either, because of the inbound firewall rules that you describe.

If inbound port 80 is your only option, weevely might be your tool of choice. Technically, it's a web shell, but at least it provides you with the look and feel of a remote shell.


Bypassing browsers URL encoding to do reflected XSS from query parameter?

It depends on the browser you are using.

Here is a blog post from Troy Hunt regarding this topic:

You can try to intercept the request using tools like Burp Suite. If you intercept the request, you can try to change the encoding character set and check if the desired result occurs.


Sharing a common public and private SSH keys for a cluster of machines

I don't think this should be an issue - using a single key pair to access many servers is perfectly fine and most of the world works that way.

Its important to understand, as @Tom Leek mentioned, that the private part of the key - which must stay secret - is only stored on your single machine and is never transfered out of it. So even if one of the servers is compromised (in a way other then someone stealing your private key), there is no way that this access can be used to gain SSH access to the other servers (although likely the attacker used an exploit that will work just as well on all the other servers as they have identical configuration).

I do have to note that your use of a "Load Balancer" to access the servers over SSH seems suspect to me: "Load Balancer" usually denotes an IP-level or TCP-level access control such that the client connect to a single IP and each time gets assigned a different backend. This is not an accepted way to connect to SSH, because you will still get a host mismatch error when the client tries to verify the host key regardless of your login key (unless you init all hosts with the same host key, which I think is a poor choice). A likely configuration is that you will use a DNS round robin configuration to address all servers as the same name, where each time it resolves to a different IP. In such a setup the client can verify each IP separately and you will not get an error.


GETRANDOM syscall's relation to kernel entropy pool state

Sysctls and the blocking pool.
You can increase the value of the kernel.random.read_wakeup_threshold sysctl. This sysctl changes the behavior of the blocking pool, forcing users of the blocking pool to wait until the entropy estimate exceeds this value. From the manpage at random(4):
read_wakeup_threshold
    This file contains the number of bits of entropy required for
    waking up processes that sleep waiting for entropy from
    /dev/random.  The default is 64.

Note however that the blocking behavior you describe only applies to the system at very early boot. Once it has enough entropy, it will change to non-blocking behavior regardless of how low the current estimate gets. This is because you only need a certain number of bits of entropy once, and can create a virtually unlimited amount of cryptographically secure pseudorandom data once you have it. The entropy estimate going down does not change this fact.
Answering your exact question
Now, is it possible to change this initial threshold for the non-blocking pool (if you don't want to learn all the nitty-gritty, skip to the end of this answer)? I suspected it was not, but I wasn't sure, so I went to consult to the most authoritative documentation available: the source. The syscall getrandom(2) is defined in the kernel randomness driver. Note that this is specific to Linux kernel 4.14 (major changes to the randomness driver were made in 4.8).
Comments added by me for clarification to the getrandom() syscall code:
SYSCALL_DEFINE3(getrandom, char __user *, buf, size_t, count,
        unsigned int, flags)
{
    int ret;

    // If the flags bitmask is invalid, return an error.
    if (flags & ~(GRND_NONBLOCK|GRND_RANDOM))
        return -EINVAL;

    // Cap the requested size at the maximum value.
    if (count > INT_MAX)
        count = INT_MAX;

    // If the blocking pool is selected, read from it and return.
    // The _random_read() function will deal with blocking.
    if (flags & GRND_RANDOM)
        return _random_read(flags & GRND_NONBLOCK, buf, count);

    // If we get to here, we know the non-blocking pool was selected.

    // Is the CRNG ready? Evaluates true if it is not.
    if (!crng_ready()) {
        // If we want to bail out and not block, return -EAGAIN.
        if (flags & GRND_NONBLOCK)
            return -EAGAIN;

        // Otherwise, block until random bytes become available.
        ret = wait_for_random_bytes();
        if (unlikely(ret))
            return ret;
    }

    // Finally, read from the non-blocking pool and return.
    return urandom_read(NULL, buf, count, NULL);
}

OK, so most of this is pretty self-evident, but what are the functions crng_ready() and wait_for_random_bytes() for? The latter is defined in the same file:
int wait_for_random_bytes(void)
{
    // If crng_ready() returns true (which is likely), return 0.
    if (likely(crng_ready()))
        return 0;

    // Otherwise, wait until it does return true before returning.
    return wait_event_interruptible(crng_init_wait, crng_ready());
}
EXPORT_SYMBOL(wait_for_random_bytes);

So now we know in the definition of getrandom() that, if the non-blocking pool is selected, it will check if crng_ready() returns true. If it does not return true, then we will wait, sleeping until it does. What does crng_ready() do? It turns out it's defined as a simple macro:
#define crng_ready() (likely(crng_init > 0))

The variable starts out as zero, but what matters is where exactly it is set to 1. It appears that this is done in the crng_fast_load() function, defined here:
static int crng_fast_load(const char *cp, size_t len)
{
    unsigned long flags;
    char *p;

    // Enter the critical section (acquire the spinlock).
    if (!spin_trylock_irqsave(&primary_crng.lock, flags))
        return 0;

    // If crng_ready() is already true, leave the critical section and return.
    if (crng_ready()) {
        spin_unlock_irqrestore(&primary_crng.lock, flags);
        return 0;
    }

    // Mix in the values at cp with the CRNG state. Increment crng_init_cnt
    // for each byte from cp that gets mixed in (up to len times).
    p = (unsigned char *) &primary_crng.state[4];
    while (len > 0 && crng_init_cnt < CRNG_INIT_CNT_THRESH) {
        p[crng_init_cnt % CHACHA20_KEY_SIZE] ^= *cp;
        cp++; crng_init_cnt++; len--;
    }

    // Leave the critical section (release the spinlock).
    spin_unlock_irqrestore(&primary_crng.lock, flags);

    // If crng_init_cnt is >= CRNG_INIT_CNT_THRESH, set crng_init to 1.
    if (crng_init_cnt >= CRNG_INIT_CNT_THRESH) {
        invalidate_batched_entropy();
        crng_init = 1;
        wake_up_interruptible(&crng_init_wait);
        pr_notice("random: fast init done\n");
    }
    return 1;
}

From this, we see that crng_init_cnt is incremented for each byte which crng_fast_load() takes in. The function is called early at boot in various entropy-gathering functions to add as much possible data to the pool early on. We're almost there! Last thing to do is find out the value of CRNG_INIT_CNT_THRESH, defined here:
#define CRNG_INIT_CNT_THRESH (2*CHACHA20_KEY_SIZE)

So it's double CHACHA20_KEY_SIZE. This one is defined in a header file, crypto/chacha20.h:
#define CHACHA20_KEY_SIZE   32

So CRNG_INIT_CNT_THRESH is 64. And there's your answer!
Recap

CHACHA20_KEY_SIZE is hardcoded as 32.
CRNG_INIT_CNT_THRESH is double CHACHA20_KEY_SIZE, making it 64.
crng_init_cnt is incremented for every byte of early randomness gathered.
When at least 64 bytes of randomness are gathered, crng_init is set to 1.
When crng_init is 1, crng_ready() evaluates true.
When crng_ready() evaluates true, getrandom() resumes and returns.

The amount of early entropy required before getrandom() resumes and returns is not in fact 128 bits. It is already hardcoded as 64 bytes (512 bits), twice the amount you wanted.


Solution: upload the file as hidden, for example: .shell.php and call the file directly.


No, it is not a security breach. It is as fine as it was before. There is no change in safety.

7.2 was created in order to warn everyone that TrueCrypt will stop being developed and practically it is a limited version of TrueCrypt's final release: 7.1a.

You should have not updated to 7.2 because there is no reason to do so and no functionality improvement from 7.1a to 7.2.

At this moment, TC (7.1a) is perfectly safe, but considering the fast-paced development of computing power, on the long term you should consider switching to VeraCrypt which is safer against brute force.


Cannot perform SQL injection because of the weird postgresql syntax that is used

Attack type
0 AND 3133=(SELECT 3133 FROM PG_SLEEP(1))
is a method of blind sql injection. Blind sqli applies time to determine the content of the database, mostly using if conditions (cf eg SQL Injection Cheat Sheet - Conditional Time Delays). So if you are interested in using this technique for dumping explore it for postgreSQL.
3133 is a fixed value and PG_SLEEP(1) delays the execution at the database for 1 second. So basically this sums up to 0 AND true with a waiting time of 1 second.
You can use this to check if this type of sqli is feasible.
Basically the referenced exploit is a proof-of-concept to show that sql injection is possible.
It is also listed as CVE.
How does it work?
I don't know what CreateReportTable.jsp does exactly. I only found this documentation. The documentation mentions:

To use Advanced Filtering, select the column name such as, Requester
name, region site and so on from the combo box.

which probably belongs to a filtering of sites/branches you can define for your company. So this could be an entry point to check where the issue is in your application. Analyse the query parameter site.
If you want a deeper understanding what SELECT 3133 FROM PG_SLEEP(1) does you can verify it using docker:

sudo docker run -it --rm --name some-postgres -e POSTGRES_PASSWORD=mysecretpassword -e POSTGRES_USER=user -e POSTGRES_DB=db -d postgres:latest

sudo docker exec -ti <your_docker_container_id> psql "dbname=db user=user password=mysecretpassword"

psql is the interactive terminal for postgres. In this terminal \dt gives you an overview about what the function pg_sleep does.
The function has a return data type of void - which is basically an empty value. Enter select * from pg_sleep(1) to double check that. This will bring you back after one second and outputs no value. At first the function is applied and then the select is executed.
The empty return value then can be overwritten by choosing a constant:
select 1 from pg_sleep(1);

Mitigation possibilities and impact
The CVE states

SQL injection vulnerability in reports/CreateReportTable.jsp in ZOHO
ManageEngine ServiceDesk Plus (SDP) before 9.0 build 9031 allows
remote authenticated users to execute arbitrary SQL commands via the
site parameter.

So probably it is fixed with an update to a higher version.
The other thing is that you have to consider a possible breach depending if and how long your site has been exposed.


As far as the network is concerned, no, you do not need to be concerned.  XArp listens to ARP broadcast packets which are sent to your machine, it does not generate traffic (emphasis mine):

  XArp will inspect every ARP packet and report attacks against remote
  machines. Some inspection modules can only work for the local machine
  (e.g. StaticPreserve), but most modules will not need any local
  information. They monitor each ARP packet and can thus detect ARP
  attacks against other machines. Be sure to deploy XArp on a machine
  that sees all network traffic from the whole subnet. XArp can only
  monitor and inspect packets that it can see.

Depending on your environment, it is possible that your Administrator does see programs; for example, many anti-virus packages will alert upon security tools.  However, I would think XArp is unlikely to trigger alerts, it's a purely defensive tool with no offensive capabilities.


Create backup Yubikey with identical PGP keys

found this blurb which says that theres a command you can run which will essentially tell your local gpg app to scan the new card and use that instead if things gel. so in the case of using a backup card, not the worst case to run an "init" to make it work.

https://forum.yubico.com/viewtopic38a1.html?f=35&t=2400

  Running

  gpg-connect-agent "scd serialno" "learn --force" /bye

  will update the secret key stubs for the PGP keys on the currently
  inserted key. So running that after key insertion will cause gpg to
  use the currently inserted key.


Will password protected files like zip and rar also get affected by Odin ransomware?

Yes. The zip or rar file will be encrypted like all other files so that they are useless for you. The only protection is making backups to another physical storage.
This will help independantly of whether the files are in a password protected rar or zip format.


Where is sshd log file and how to explain the log info?

Bad protocol version identification 'GET / HTTP/1.0' from 23.252.100.22 port 38876

It sounds like a bot is sending incorrectly-formed messages to sshd. Not only is that not a version string, but it's one line of an http request - which doesn't make any sense in the context of ssh.

It could be trying to trigger some vulnerability that I don't know about, but I think it's probably just poorly programmed.

Either way, the answer is the same: do your standard sshd hardening. Disable password auth, disable root login, install and configure fail2ban.


Is SHA1 / PBKDF2-HMAC-SHA1 indissociable from random data?

Is there any scientific proof, meaning information theoretic secure? No, however there is no known way to distinguish the output of a good cryptographically secure hash from random data of the same length. Someone can probably guess something is SHA-1 if it's 160 bits, because most random-looking chunks of 160 bits tend to be SHA-1 digests, or sometimes RIPEMD-160, but it has nothing at all to do with the content of the digest, only the size.

Note that in the future, there may be new mathematical techniques discovered (invented?) which find a bias in SHA-1 or SHA-256 digests. It could range from so academic as to be almost silly ("after 1091 known plaintexts, then with 1091 operations and 1091 memory, you can calculate what the 6th bit will be with a 0.05% higher probability than chance") to absolutely devastating ("a preimage attack in SHA-256 can be achieved with $5000 worth of consumer hardware and a 300 line C program in a couple weeks"). While obviously the latter is far less likely, they both can happen. We just can't know which it will be, and have no way to predict it. However you can probably rest safe knowing that for the vast majority of randomness distinguishability attacks (the ability to tell when pseudorandom data is not actually random) requires a truly vast number of samples, likely far more than you will ever encrypt in your lifetime.

There are a few exceptions, like RC4 which has a bias in the first few bits, ciphers with a 64 bit block size like Blowfish and CAST5 which show distinguishability after several gigabytes, and block ciphers in xts-plain mode which take a few terabytes of data encrypted with the same key to cause problems, but they are not the rule.

If you are still worried, you should know that the Linux kernel, which is relied on for security in billions of devices all around the world, generates randomness by mixing a pool using SHA-1, and exporting the hash values to /dev/random and /dev/urandom, both of which produce exceptionally high-quality random data. If SHA-1 were not extremely well trusted, it would not be used so ubiquitously (note that SHA-1 running into the end of its life for protecting against collisions in certificates has no effect on its ability to look random). In case you're wondering, there's no security reason it's using hash mixing instead of a stream cipher. It used SHA-1 to get around now-obsolete export restriction laws, and it just stuck. Other systems like OSX and FreeBSD use Yarrow, OpenBSD uses ChaCha20, etc, but SHA-1 is just as secure, as far as we are aware. Just a lot slower to mix!

Why don't you just use TrueCrypt though? It supports plausible deniability, which seems to be what you are after, and both cryptsetup and GRUB2's cryptomount support it. Cryptsetup natively converts it into dm-crypt mappings, just like LUKS.


Can I view a user's browser history if the history/cache has been cleared?

There's two ways, the hard and the easy.
The hard way: use forensic software to recover deleted files, identify the folders and files responsible for history and cache, and read those files.
The easy way: use forced proxy company-wide, and configure the network to only allow browsing by using this proxy. With user authentication enabled, it's possible to know exactly what every employee is accessing.
Either way, usually the employer have to tell every employee about the inspection and require them to acknowledge that they know about the monitoring. It depends on your jurisdiction and current laws, but usually is a good thing to do.


Why is SHA-3 (keccak) considered more secure than DES when you can attempt to crack it 3x faster?

SHA-3 is a hashing algorithm. DES is an encryption algorithm. The two are not comparable. They do different things and do them in different ways.

It's a bit like asking why your blender is faster than your bicycle.


Router detecting constant ack flood attacks and port scans

The Internet is a wild place; there are tons (as in, hundreds of thousands or even millions) of script-kiddie bots constantly scanning every single IP address looking for open ports they can connect to or unsecured servers they can exploit. This is most likely likely the kind of activity that you're seeing.

Fortunately, the vast majority of consumer routers can easily defend themselves against this stuff because they ship with a firewall that, by default, will block all incoming connections and only allow outgoing connections. It looks like yours does too, based on the WAN Rule:Default deny which shows up in the snippet you posted.

So basically, there's probably not much you can or need to do about it. But in general, to keep your router secure you should:

Verify that your router does not have any incoming ports open (which you can do using the GRC Shield's Up website "All Service Ports" scan)
Keep your router's firmware up to date by checking the manufacturer's website for updates
Make sure you change the default administration interface password to something more secure
If it's a wireless router, make sure the wireless is secured with WPA2-PSK and a strong key; also make sure WPS is disabled
If there is an option to enable remote administration, disable it.

As for the "Authentication Success" messages in your log, could it just be you logging in to the administrative interface to check the log?


Are there any successful cases of timing attacks over the internet?

It might be tempting to assume that network latency (jitter) makes these attacks impractical. This is not the case because TCP timestamps are often used by the vulnerable machines, where the precise time the packet was generated is encoded into the TCP header. No matter how long it takes the traffic to arrive, the exact time it was created is still present. Even on systems with timestamps disabled, it is possible to get an accurate idea of the packet timing by repeating the test multiple times and averaging the result to account for network jitter. So, with that in mind...
Yes, timing attacks can be done over a network. The most prominent example was a long-lived vulnerability in OpenSSH that allowed trivial user enumeration. The issue was caused by the fact that an invalid user would trigger password comparison using Blowfish, the default. When a valid user was used, SHA-2 would be used instead. While normally the timing difference is minimal, sending a large password (several kilobytes) would cause the difference to be noticeable.
From the original bug disclosure:

When SSHD tries to authenticate a non-existing user, it will pick up a fake password structure hardcoded in the SSHD
source code. On this hard coded  password  structure  the password hash is based on BLOWFISH ($2) algorithm.
If real users passwords are hashed using SHA256/SHA512, then sending large passwords (10KB)  will result in shorter
response time from the server for non-existing users.

Attacks against these types of bugs often exploit the fact that a different code path is taken depending on the input you provide, causing a significantly greater timing difference than is typically seen with low-level architectural timing attacks where the differences are measured in nanoseconds and come from instructions not executing in constant time (flush+flush, etc).


Why should I restrict the content type of files be uploaded to my site?

It must be noted that a file does not have an inherent "content-type" per se. A file is a bunch of bytes, and has a name. When you download a file from a Web server, the server infers a content-type (such as "application/pdf") from whatever clues it can find, mostly the so-called "extension" (the few letters at the end of the file name; e.g. ".pdf" is assumed to indicate a PDF file), and sometimes the file contents themselves: for instance, when a Web server distributes an HTML file, it also looks within the file header for a "meta" tag which would override the default choice for Content-type, like this:

<head>
<meta http-equiv="content-type" content="text/html;charset=UTF-8" />
</head>

So you have two operations on your server: upload, and download. Upload is mostly safe: the file comes, and is stored. Download can be a worry: when an administrator will download a file, he will do so by clicking on some link within a Web browser, and the Web server will infer a content-type, as described above. The Web browser will then use the content-type to decide what to do with the downloaded file, and this might not necessarily be "suggest to the user to save it somewhere". For instance, if someone uploads a .html file, the Web browser will interpret it as HTML, displaying it and possibly executing whatever Javascript is in it. Furthermore, the file will come from your own server, so chances are that the administrator Web browser will trust that file by default. Various nasty things may happen at that point.

So you should filter the content-types under which you will serve the files when downloaded; and mind the file name, too, because even if the file is just saved on the administrator system, it may still be a .exe file which the administrator will execute when clicking on it.

Moreover, allowing any kind of file to appear on your server may be an indirect tool to leverage an attack. There are some security holes in which the attacker can somehow force the execution of an arbitrary file on the server; an unfiltered upload mechanism allows the attacker to first push exactly the kind of executable file he would like to see executed on the server.