Just looking at the OWASP Top 10, most issues are server-side:

A1 Injection: SQL Injection, Command Injection, etc.
A2 Broken Authentication
A3 Sensitive Data Exposure
A4 XXE
A5 Broken Access Control (OWASP places eg directory traversal here, as well as IDOR, privilege escalation, etc)
A6 Security Misconfiguration (mostly server-side)
A8 Insecure Deserialization
A9 Using Components with Known Vulnerabilities (mostly server-side)
A10 Insufficient Logging & Monitoring

They also list some server-side issues under "Additional risks to consider" such as unrestricted file upload, application-level DOS, or SSRF.

The only issue that could be classified as client-site is:

A7 XSS

OWASP doesn't list a lot of client-site issues though. Some, such as CSRF, Open Redirect, or Clickjacking are listed under additional risks. OWASP also places some issues that are exploited client-side in the above categories (eg CORS issues under broken access control).

Note also that while XSS is often considered a client-side issue, classification isn't that easy, as the vulnerability itself is mostly introduced server-side.


Wiping an SSD with Parted Magic seemed too quick

Modern SSDs use a technology called SED which allows instant erasure. It works by transparently encrypting the entire drive and keeping the key on the drive. ATA Secure Erase is then implemented by wiping the key alone, which renders the rest of the data immediately unreadable (assuming of course that it has been correctly implemented on that particular storage device). The reason two minutes specifically is quoted is because it is the minimum value the ATA protocol can report.
But note a potential caveat: Recovery of EEPROM data after bulk erase operation


Protect hidden message in image from manipulations

I believe that there is some old research (like this or this on lossy-compression tolerant stego, but not I do not know if there are any guarantees provided or real-world implementations. At the end of the day, there are too many possible manipulations and it is unrealistic for a tool to handle all possible image transformations (but I haven't tried this in years).

You may want to pre-empt users compressing your files by using a JPEG-based stego tool that already performs compression. Try Red JPEG XT or StegaMail.

One thing you should handle is that an attacker could intentionally modify your hidden message. You may wish to include an HMAC within your message if all your tool supports is encryption-and-encoding and not message integrity.


Answer depends on your security model.

Classically, a cryptographic hash function has three properties:

It resists preimages: given y, it is infeasible to find x such that h(x) = y.
It resists second preimages: given x, it is infeasible to find x' such that x ≠ x' and h(x) = h(x').
It resists collisions: it is infeasible to find x and x' such that x ≠ x' and h(x) = h(x').

For a "perfect" hash function with an output of n bits, the resistance is up to effort, respectively, 2n, 2n and 2n/2 (regardless of how strong the function is, "luck" still works with a small probability, and that gives these average costs for finding a preimage, a second preimage, or a collision).

When you truncate the output of an existing hash function, you are in fact defining a new hash function, and since that hash function has a smaller output, its resistance is correspondingly smaller.

The good question is then: which of these properties are you relying upon ? This depends a lot on the context.

For instance, suppose that the attacker's goal is to alter an existing piece of data, without being detected through a hash function mismatch. This is a second preimage situation: attacker sees a message m and tries to find a modified message m' that hashes to the same value. In that case, truncating to 10 bytes means that you still have resistance 280, a huge number that will deter all but the most determined or irrational attackers. Note, though, that an attacker may have a choice of targets: if the attacker sees 100 messages, and wants to modify one of them (with no preference over which can be modified), then "luck" works 100 times better. Thus you may want some extra security margin and keep, say, 12 or 13 bytes of output.

Now if the attacker can get to inject his own innocent-looking message m, that you validate and hash, and will later on replace it with a distinct message m' with the same hash value, then this is a question of collisions, thus working with resistance 2n/2 for a n-bit output. In that case, truncating the hash function output is a quite bad idea.

The safe course is not to truncate anything. After all, as I write above, truncating the output is equivalent to designing your own hash function, and, in all generality, this is very hard to do properly. SHA-1 has a 160-bit output precisely so that you get "at least 280 security" in all cases. Determining whether collisions apply to your situation or not can be hard.

Also, remember that a hash value does not create integrity; it just concentrates the issue. When you hash a piece of data, you get a hash value, and that hash value will guarantee that the original data is unchanged only insofar as you can be sure, through some other means, that the hash value itself was not altered. If you store the hash value along with the data that is hashed (your "input"), and the attacker is assumed to be able to alter the stored data, then what exactly would prevent him from modifying the hash value as well ? Whenever he wants to put m' instead of m in some database cell, he may also put SHA-1(m') into the neighbouring cell, overwriting the SHA-1(m) that was there, and you will be none the wiser.

If you want to use hash values to protect data integrity, then you must ensure the integrity of the hash values themselves in some other way. Hash functions reduce the problem: instead of protected a 1-gigabyte file, you "just" need to protect a 20-byte hash value. But you still have to do something.

Cryptography can help you further concentrate things by using a MAC instead of a hash function. With a MAC, you have a secret key, and you can use one key for millions of MAC computed over millions of "inputs". There again, you still have to do something, but that something is: keep confidentiality of a single key (of, say, 128 bits) for the whole of the server.


Whitelist VPN provider's IP address in cloud service provider

While restricting the address space that is allowed to access the ports is always a good idea, both your options are equivalent, generally speaking.

If your local ISP has as many customers as the VPN provider - or both numbers are in the same ballpark - you have equivalent security gains if the ISP uses an IP pool where you regularly get a new IP from that pool. There's one thing to consider though: VPN providers allow access from everywhere for basically everyone who wants. This is either a pro for you while you travel and do not have an IP from your local ISP assigned or a pro for an adversary that is not able to get service from your local ISP.

If restrictions on the ACL are so wide, either way, you should still consider the ports public and use public key authentication rather than password authentication and keep your machine up to date.

If you only use the currently assigned ISP's IP or if your ISP does not use a pool, you'd be better off using that IP to whitelist.

If you need to access the services while away, you might host a VPN proxy in your home network


WEP might as well be open these days. If you have to use a known insecure network - use a VPN. That's what they're for. Attacker can see you're running nothing but encrypted traffic to a single endpoint, and can infer that you have a VPN, but that introduces an entirely different class of issues, tools, and skills to attempt to compromise.


Is it true that the older the files are, the more likely it is they are clean if new scanners won't detect anything?

Antivirus vendors and administrators tend to disable scanning routines and pattern detection for older malware generations. They usually do this for performance reasons. The legitimization is, that old malware might be eliminated anyway in the meanwhile because there were so many detection mechanisms established for so long which would make it impossible for an ancient malware to survive. I did an analysis of the default protection filters of HP TippingPoint and revealed the same in the IDS/IPS sector.

The problem is, that the reasoning is wrong. Older malware might have survived because everyone thought it is extinct. There is a similar problem when it comes to vaccination.

Besides that it might be possible that an attacker/malware manipulated the timestamps of a file. Without integrity checking you can't tell if this really is the file that you expect it to be since an earlier point in time.


If I have the input and output, can I know the encryption technique?

As @David's answer pointed out, this is, in general very hard to do. Especially since some encryption algorithms like AES use a random initialization vector (IV) as the starting block. So correct implementations would generate a different IV each time, even if the plaintext is the same, resulting in a different message.

As an example, let's encrypt Hello World! in CBC mode with:

key: 0000 0000 0000 0000 (not secure, just for illustration)

If I use IV = 0000 0000 0000 0001, I get ciphertext (base64): KcS/oAzkKMi03Nrf65hlww==

If I use IV = 0000 0000 0000 0002, I get ciphertext (base64):
2wTIRW8sSb4XpE9Ue3xm6w==

(The IV is usually included with the encrypted message. I omitted it for ease of comparison)


Can't free proxies be used to create a botnet?

A bot (as in botnet) is something different than  a proxy. While attackers can use proxies to hide their own IP address from the target they can not actually control the proxies with small commands to mount large attacks against some target. A proxy just passes through the original traffic, i.e. an attacker would need to have lots of bandwidth by its own to mount an attack against some target with the same bandwidth.
A bot instead provides a way for the attacker to run arbitrary actions. Specifically it is possible to control lots of bots with only little bandwidth, but let these bots then mount bandwidth-intensive attacks against the DDoS target.


Are contents of PHP sessions forensically valuable?

Whether or not the PHP session had any forensically useful data in it really depends on what kind of information that the application stores in the session. So yes, if applications store forensically useful information in the session (which is quite common) then the session files will have useful data in it.


UEFI firmware launches the Windows bootloader when it has been correctly verified (it's been signed by one of the entities your firmware trusts). Once on the Win bootstrap, there is a module that verifies code integrity of every module in the kernel. All the drivers/modules that are not signed or signed by an entity not included in the code integrity db are simply rejected and the boot process will fail warning the end-user.

Now, you can override that policy to even load unsigned drivers. OK, but what about user delivered apps/programs? Well there exists something called code integrity where a developer signs his software including a timestamp, so if the certificate expires somehow, that timestamp validates the signature. It's a security matter that entirely depends on you, you are exposing yourself installing unverifiable software, so be sure that the source is reliable when code signing is not included.

I'm not an active Win user right now but I'd say that most of the shipped software included in any modern Windows OS is directly signed by Microsoft following the code integrity specs. Look also for signature catalogs, it's very instructive. Now, if you were a Linux user, software downloaded from official repos is guaranteed to be signed so signatures can be validated with pgp keys of the repo, there have been cases of compromising the official repositories, so danger it's still out here for us all.


Looking at the specifications you've posted, its a SATA 3 compliant disk supporting 6 Gbps signalling speeds. That matches up to most current generation desktop/laptop hard drives which are quite capable in terms of I/O speeds.

The additional overhead of Disk encryption is actually placed on the processor and lesser overhead on the drive.  If you're going to be using CPU intensive workloads coupled with disk I/O intensive workloads on your system then, disk encryption will definitely slow you down. To mitigate this somewhat you can switch over to the latest generation intel Broadwell processors have improved AVX instructions which speed up encryption workloads.

But when evaluating whether to deploy disk encryption, consider the costs and the impact of a possible data theft vs. cost of the solution and cost of performance penalty on the system.


Best practices for Private Key management

key management for (highly sensitive) private keys is usually achieved by storing them within hardware crypto modules (also referred to as HSMs).
there are varying levels of hardware crypto modules, which are usually rated in line with the FIPS 140-2 standard

The hardware resides either on the machine (e.g. PCI card), or on the network (also known as a network-based HSM).

Where it starts to get tricky is if the application is virtualised, or where you need to start to share the key between many hosts (e.g. 16 web servers that all use the same certificate).

For HTTPS scenarios:
As a scale-out option i've seen a lot of people go to load-balancers, and use them to terminate the initial connection from client's browsers. Some load balancers have an option of storing the key onboard in hardware. From there, you have an option of initiating another connection to your web server (that sits behind the load balancer), or going cleartext, since the traffic is now on a semi-protected(?) network.


There are a variety of approaches to promote the discovery and fixing of software vulnerabilities.  The most common ways to provide compensation to researchers are bug bounties (run by vendors) and vulnerability brokers (who buy and sell information on vulnerabilities applicable to popular software).  These are well described in A Comparison of Market Approaches to Software Vulnerability Disclosure (2006) by Rainer Böhme, but he notes that they are each badly flawed and don't lead to the kind of research investment or vendor engagement that we need to deal with the enormous problems of insecure software.  The black-hat vulnerability brokers, who don't release the exploits to the vendors, pay much more (a factor of 10?) to black-hat researchers than the more ethical brokers do.  The result is that a large fraction of the research goes underground and contributes to Internet insecurity rather than security.
I think that Böhme's proposal for exploit derivatives is a very promising form of market to explore, to achieve exactly what you're talking about.  It gives researchers a way to make money by discovering a vulnerability without having to disclose it in a dangerous way.  As Böhme writes:

consider a contract that pays its owner the sum of 100 EUR on, say, 30 June 2006 if there exists a remote root exploit against a precisely speciﬁed version of ssh on a deﬁned platform. It is easy to issue this kind of contacts, since you would sell it as a bundle with the inverse contract that pays 100 EUR if the ssh program is not broken within the maturity. Then, diﬀerent parties can trade the contracts on a electronic trading platform that matches bid and ask prices, settles the deals, and publishes the price quotes.
[This kind of market would attract a variety of groups of market participants:]
software users would demand contracts paying on breaches in order to hedge the risks they are exposed to due to their computer network.....
Software vendors could demand contracts that pay if their software remains secure as a means to signal to their customers that they trust their own system; or contracts that pay if their competitors’ software breaks.....
software vendors [could] use exploit derivatives as part of their compensation schemes to give developers an incentive to secure programming....
Finally, security experts could use the market to capitalize eﬀort in security analyses. If,
after a code review, they consider a software as
secure, they could buy contracts on the secure
state at a higher rate than the market price.

They are an application of "Binary options" to security events.  See Exploit Derivatives & National Security
 by Micah Schwalb for more details.
The main problem seems to be that various laws can be used in various jurisdictions to inhibit the flow of information about vulnerabilities, as Schwalb discusses, so that is something to work on, and he proposes an idea for enabling a pilot of this kind of market by making exceptions to the law for the emerging important but risky world of ipv6 vulnerabilities.
See other options, and more discussion on this site at: Progress in market approaches to software vulnerability disclosure? - IT Security - Stack Exchange


Is there a service that will auto scan a 'Terms if Service' to assess privacy issues?

No, and there likely won't be until AI takes over the Earth. A legal document must be read and understood -- there isn't any kind of automated reader that can point out issues for you. It is already difficult for humans without a law degree to do so.


How do I block LinkedIn from extracting data from Microsoft Exchange Server?

There are two different matters here, Outlook Social Connector LinkedIn integration and LinkedIn Outlook contact import. These are totally different things.

Importing contacts from Microsoft Exchange: In this case, LinkedIn has no access to your Inbox at all. LinkedIn could indeed have access to the user's inbox. The whole process is controlled by an API provided by Microsoft Exchange itself, it's called Exchange Web Services (EWS). It's up to you to configure the access rights and information shared by EWS.
You can block this by using the Set-OrganizationConfig cmdlet, then setting the EwsApplicationAccessPolicy value to EnforceBlockList and adding LinkedInEWS to your block list. Now your users won't be able to import their contacts and send them to LinkedIn.

Outlook Social Connector LinkedIn integration: In this case, the core of the deal between Microsoft and LinkedIn was to provide social functionalists for Outlook, and to provide LinkedIn an access to millions of address books and inboxes in the corporate world. So if you don't want LinedIn to have access to your inbox, you shouldn't integrate LinkedIn with your Outlook Social Connector.


Is there a way to access PKCS5 or 7 padding in OpenSSL without encrypting something?

PKCS#5 padding is defined relatively to the block size of the underlying block cipher. If there is no block cipher, then there is no block size, and thus the padding is ill-defined.

Nevertheless, if you take as extra input the block size s to use, then the padding is not hard to implement. If the data length is n, then the padding adds exactly k bytes, such that:

1 ≤ k ≤ s
n + k is a multiple of s
the k bytes all have numerical value k

These rules make the padding unambiguous. There is exactly one solution for k, given by the equation: k = s - (n mod s). Here is an ugly shell script (for Linux) which adds the padding to an input file:

#!/bin/sh

input="$1"
s="$2"
n=$(wc -c < "$input")
k=$(expr "$s" - "$n" "%" "$s")
sk=""
for i in $(seq "$k") ; do
        sk="${sk}$(/usr/bin/printf "\\\x%02X" "$k")"
done
cat "$input" ; /usr/bin/printf "%b" "$sk"

(use the input file name as first parameter and the block size as second parameter; the padded file is written on the standard output.)

The reverse operation is left as an exercise (shell programming is not very adequate for this sort of treatment).


What is a spinner (empty while loop) doing, and why?

I see a couple of different "spinners" when grepping the code. The one you reference appears to be unused:

static void spinner_empty(mach_port_t* arg)
{
    while (!*arg)
        ; //spin
}

static void spinner_nonempty(uint64_t* arg)
{
    while (*arg)
        ; //spin
}

spinner_empty looks like it waits until the mach_port_t that arg points to casts to true rather than false, and spinner_nonempty waits for the uint64_t arg points to to be 0. I have no idea what purpose these serve, as they appear to be unused right now.

There's also this one:

// in the end I don't use these, but maybe they help?

volatile int keep_spinning = 1;
void* spinner(void* arg)
{
    while (keep_spinning)
        ;
    return NULL;
}

#define N_SPINNERS 100
pthread_t spin_threads[N_SPINNERS];

void start_spinners()
{
    return;
    for (int i = 0; i < N_SPINNERS; i++) {
        pthread_create(&spin_threads[i], NULL, spinner, NULL);
    }
}

void stop_spinners()
{
    return;
    keep_spinning = 0;
    for (int i = 0; i < N_SPINNERS; i++) {
        pthread_join(spin_threads[i], NULL);
    }
}

In this case it looks like they may simply be there to slow down execution, by having a large number of threads constantly spending as much time as possible doing nothing. The comment seems to indicate that they may not be necessary, but the author thinks perhaps slowing down the execution may give the exploit a higher chance of success.


Email is usually/historically encrypted using PGP or GPG. There are PGP and GPG addons for most common browsers;

You will need to generate a key-pair for yourself and follow basic key-management procedures. This is all fairly long-winded to put into an answer on here, but there are some GUIs available that make the process easier, such as GPG4Win.

The major caveat with all this is that you will need to convince your friends to participate. They have to decide to send you encrypted email, and likewise they have to set up a key pair themselves in order for you to be able to send them encrypted email.

This lack of a ubiquitous web of trust subsystem is why email encryption is still very much underadopted. The widely used PKI doesn't lend itself so well to email, as it lacks flexibility and is prohibitively expensive.

Email at its core is just raw text transfer. That doesn't change when you start encrypting things. Typically the body of the message is encrypted using the public key of the recipient. This encrypted message is formatted into printable characters (usually with base64 encoding), this stage ensures that the encrypted block, which might contain weird and wonderful bit-sequences that map to weird, unprintable characters, is transferred safely by encoding it in simple characters (base64 uses the alphabet, numbers and a few common symbols).

The browser addons are able to identify this encrypted block inside the web page, and will allow you to decrypt it, which returns it into a plain text format.


How to ensure if an SSH tunnling failed (if I haven't really tunneled)

After running netstat -tulpn I did saw to conenctions, one is to port 22, and one is to port 80.

So it seems the tunneling didn't fail.


Legality of downloading leaked hashes / attempt cracking

Starting with the huge caveat that this may or may not apply based on your locality and is not in any way legal advice, a large portion of cybercrime laws are based around illegally accessing resources.  If you use a computer system in a way that it was not intended to be used, you could be prosecuted by the owner of the system.  This is essentially laws in the vein of trespassing.

Now, one could make the argument that the list is stolen goods, however that often doesn't really hold up very well as it isn't stolen, it is a copy.  The copy was obtained by trespassing to get it, but the information itself (unless protected by intellectual property somehow) is not actually stolen.  It is the user's copy even if illegally obtained.

In most cases, that means this information can be distributed just as freely as any other leak.  The copy of the file belongs to the attacker and if they release it, then accessing it is probably legal.

Now, that could be wrong if your local jurisdiction may have laws that make it illegal specifically, but it becomes a tricky slope if you are responsible for determining if every single thing you access was legally obtained.  Again, most of the precedent of this kind of thing stems from intellectual property and is most often civil law rather than criminal.

One thing is certain, it is a complex legal issue with no immediately clear solution.  It will take time for the legal system to catch up with the 21st century in a way that helps prevent cybercrime but that doesn't cause unintended consequences at the same time.

Your best bet, as always, is to talk with a lawyer in your local jurisdiction that is up to date on the laws where you are rather than talking to a random developer on the internet that just happens to follow the applicable laws half hearted and casual.


Risk when attacker has only physical access to a computer's USB port

If a USB port was available, any attack could potentially trick the computer into believing a small plug was a keyboard, making it possible to save and run scripts on the computer.

They could also run a program on your computer by using the Autorun feature on your computer, although that feature could also be disabled.

Practically anything can be done, but it's dependent on whether or not the computer will allow it to be done.


Serving a php webshell without running it locally

Use the following setting in your apache config or in a .htaccess file:

php_flag engine off

See also Disable PHP in directory (including all sub-directories) with .htaccess.


Without an understanding of the underlying language, one problem you may have is understanding context.

While it may be best practice to eschew these banned functions completely, I see a lot of projects where some of these functions are used, but in safe contexts. If you raise a red flag simply every time you see one of these functions in use, you may have a bad time.

Here are some examples using the infamous strcpy and its slightly safer version strncpy:

void foo_1(char* bar) {
    char buf[100];
    strcpy(buf, bar);
    puts(buf);
}

char* foo_2(char* bar) {
    char* buf = NULL;
    buf = malloc(strlen(bar)+1);
    strcpy(buf, bar);
    return buf; // freed later
}

void foo_3(char* bar) {
    char buf[100];
    strncpy(buf, bar, sizeof(buf));
    puts(buf);
}

void foo_4() {
    char buf[100];
    strcpy(buf, "This is just an example.");
    puts(buf);
}

If I did this correctly, these examples should be:

Unsafe (if bar is longer than 100 bytes, an overflow will occur)
Safe (buffer is created large enough)
Unsafe (produces un-terminated string when there are no null bytes in first n bytes of bar)
Safe (string is constant and smaller than buffer size)

From the strcpy manpage:

  If the programmer knows (i.e., includes code to test!) that the size
  of dest is greater than the length of src, then strcpy() can be used.

If these examples are challenging, you may want to brush up on your C programming, as these are by no means complex examples.

Additionally, while the "strn" family functions also may appear on the banned list, many projects use these safely as well by forcing a null byte at the end, often done with a wrapper function.


How do I create a valid email certificate for Outlook S/MIME with openssl?

The dialog box in #1 is expected when operating under Medium security.  The OS is supposed to verify the PIN before using the key for the first time.

The dialog boxes in #2 and #3 indicate more of a file-based permissions issue.  Are you doing this in Cygwin under Windows or a Unix host and transferring the file over?  There might be a problem in the chmod at the end under Cygwin.

Consider removing the "-clrtrust -addtrust emailProtection -addreject clientAuth -addreject serverAuth -trustout" options and seeing if it works when all intended uses are allowed.  Then start scaling back the intended uses.

For example, the following works for me, but obviously has "all" intended uses which may not be desirable:

$ openssl genrsa -aes128 -out email.key 2048
$ openssl req -new -key email.key -out email.csr -config email.cnf
$ openssl x509 -req -days 365 -in email.csr -CA ca.crt -CAkey ca.key -set_serial 10 -out email.crt
$ openssl pkcs12 -export -in email.crt -inkey email.key -out email.pfx

I use a very basic cnf file:

[ req ]
default_bits           = 2048
distinguished_name     = req_distinguished_name
prompt                 = no

[ req_distinguished_name ]
C                      = {Country}
ST                     = {Provice/State}
L                      = {City}
O                      = {Org}
OU                     = {Org Unit}
CN                     = user@domain.com
emailAddress           = user@domain.com

Load the email.pfx into the Windows Certificate Manager into your Personal certificate store.  Now, I have Outlook 2010 running under Windows 7, so I have to also create the entry I will use for default security settings.  This involves going to the Outlook Trust Manager (File | Options | Trust Center | Trust Center Settings | Email Security).  The "Encrypted Email" grouping is where you can create a new "Default Setting" which includes the newly imported certificate.  (The "Import/Export" button in Outlook 2010 can be used as a way to import the .pfx into the cert mgr.)


Generally, these smart devices have a third component - the service provider.

Using Nest as an example, when you connect it to your wifi network, it connects back to Nest servers so that the Nest iOS or Android app can make changes to your home device remotely. You don't need to connect directly to your home network.

The most direct security benefit being that you don't need to expose your home network to the internet, which is unsafe.


If someone spoofs your Gmail account, there is no possible way for you to know that. That would be like being able to know if I introduce myself to others as Ali Zahy. The receivers would know if they inspected the headers of those emails, though.

You might be able to determine if your actual account was used to send emails by looking at your sent and deleted folders. But if the malicious emails were permanently deleted, there would be no way for you to know. But, again, the proof is on the receiver's side.


Testing security tools for non-standard protocols

Sounds like a job for nmap (IP Protocol scan) or scapy. Older tools such as isic or ip6sic are in the same class, as are point-commercial solutions such as Codenomicon or Beyond Security and big players like Spirent and Ixia.

Probably my favorite tool for working with non-HTTP/TLS traffic (for those protocols, I'd use Burp Suite Professional) is Canape. Canape is a pluggable proxy, so I can record packets and frames in order to play with them. If I really wanted to hire a firm to help with testing security appliances, I'd look at Deja vu Security for their Peach Fuzzing Framework intellectual property, instructional capital, and thought leadership.


Frameworks or any Solutions for authentications/security/ login management in Java Web Applications

Check out OWASP's ESAPI (Enterprise Security API).

  ESAPI (The OWASP Enterprise Security API) is a free, open source, web application security control library that makes it easier for programmers to write lower-risk applications. The ESAPI libraries are designed to make it easier for programmers to retrofit security into existing applications. The ESAPI libraries also serve as a solid foundation for new development.

While it is ported to several languages and frameworks, it started as a Java EE project. It's a very large and flexible framework, should meet most of your needs.

And as far as authentication and user management goes, strongly consider using OpenID (or something like that), so you dont have to manage it at all. Depending on your usecases and userbase, this can be a huge benefit, to you AND your users.


RC4 in TLS is subject to bias problems. In a pragmatic sense, while this has been exploited in lab conditions, it isn't very likely that you'll fall victim to it in practice. However, the cost of disabling RC4 suites is usually zero; the only systems that still have no AES support are Windows XP on Internet Explorer, and if you're still supporting such clients then you have much bigger problems than RC4.

(EDIT: As per Thomas' comment below, XP doesn't support ECDHE either, so this suite still wouldn't work on XP anyway)

TL;DR - disable it, there's no good reason to keep it around.


I would recommend using several unique identifiers in this case, e.g. user's cookie with some random and unique string, let’s say USER_ID, and a session token e.g. SESSID. The session token should expire as it is supposed to, however the USER_ID remains. This way you will be able to identify users, who have previously visited your website and still use new SESSID as protection against CSRF.

Extending lifetime for sessions is not a good idea, especially if you use this token to verify user's identity (in case with admin account).


Is using the md5 hashing algorithm as method for authorization in an HTTP POST request unsafe?

This idea raises red flags in my head for a few reasons:

MD5 is broken in a way that makes it possible for an attacker to compute a colliding hash, such that md5(a + b) == md5(a + c) without having to know b. In this case, a is your user ID, and b is your secret. As such, MD5 is is a bad choice here. SHA family hashes are also a bad choice, because they rely on the same construction and suffer the same issue. Update: No, I got this wrong. MD5 isn't quite as broken as I thought. Regardless, the following points hold true...
If you're relying on MD5 for brute-force resistance, you're going to have problems. MD5 runs way too fast for that kind of thing. You need to use a slow KDF such as PBKDF2 or bcrypt. Even so, this seems like an odd use for a hash or KDF.
The salt seems to serve no purpose here. Salts are used to prevent precomputation attacks such as rainbow tables and hash databases. If the goal is to prevent replay attacks, the salt will not help you here. An attacker will be able to replay your authentication messages.
An attacker can modify the request in-transit, by performing a man-in-the-middle attack. In doing so he is free to arbitrarily alter these messages.

The only way to properly do this is to use HTTPS (i.e. TLS) for the connection. This provides authenticity and confidentiality, and prevents replay attacks.


The first question that comes to my mind is : Why combinig them ? To make bigger frames ?

If you use a single frame containing 3 messages instead of 3 frames each containing a single message the overhead is smaller.

  After the ClientHello, the server sends 3 frames in a row (ServerHello, ServerKeyExchangeand ServerHelloDone), and the client can't catch every one of them.

Since this is a TCP stream messages cannot be lost. It looks more like your client is doing the receiving of the messages in a wrong way. Often this means that the client is implemented to expect exactly a single message with a single read, but these can be even half messages etc because TCP is a stream and not a message protocol.

  My second question is : Could this "combining" bring security breaches ?

The information exchanged are the same. It only matters how much frames you need to transfer the information if somebody is unable to get all the data. But again this would be usually only because of a buggy design of the client/attacker and not a problem of the protocol.


updateprofile.php?uid=1  I can change to

  updateprofile.php?uid=2

If you can change the uid parameter and then tweak other persons profile that would mean the backend application has no checks as to determine if a user is eligible to perform an action.

This attack can be a combination or any of the following including (bad session management,url tampering,indirect object reference,parameter tampering)

  So how I can prevent this type of attacks? By using Session variables?
  Encrypting the data through the URL?

Yes,SESSIONS combined with logical checks are the way to solve such attacks.

  I am sure sessions are vulnerable to XSS or Session Hijacking Attacks.

SESSIONS have nothing to do with XSS.

  So what is the best approach for this? Coding approach etc.

The coding approach is to use SESSION Token to uniquely identify a user.Then perform server side checks to determine if a user is authorised to perform an action such as editing a profile.If he isn't simply don't allow him.


Is encrypting a CRC with the plaintext ok?

I wouldn't do this and don't understand what problem you are trying to solve (unless this is a purely academic question).

Encrypt-then-MAC where we define ciphertext=encrypt(K_enc, msg) and sending ciphertext||MAC(K_mac, ciphertext) will detect any transmission errors or malicious tampering by someone who doesn't know the secret MAC key K_mac with overwhelming probability; e.g., if you used an 80-bit MAC the probability of tampering a message and getting the MAC to pass is 1 in 2^80 ~ 8 x 10^-25 which is negligible.  E.g., if someone generated a billion forged messages every second, it would take about 3.2 million years before they had an 8% chance of a single successful forgery (or about 26 million years before they have a 50% chance of a single successful forgery).

So the 80+ bit MAC provides strong security against successful forgeries or transmission errors by itself.

Meanwhile, the 32-bit non-cryptographic non-keyed CRC32 hash does not provide any additional integrity check against someone deliberately tampering with a plaintext message they can guess, at least with stream ciphers (or block ciphers acting like a stream cipher like CTR or the one-time-pad) where XORing a change to the ciphertext modifies the same bits in the plaintext.  E.g., as CRC32's do not involve any secrets, they can guess the original message m, calculate it's CRC32, take their intended tampered message m' and calculate it's CRC32, and then modify the ciphertext in transit to c' = c XOR (m || CRC32(m)) XOR (m' || CRC32(m')).  Granted, the keyed MAC provided by authenticated encryption does prevent this attack.  However, if you had a bad implementation that said provided information (either through an error message or change in timing) of a difference between the MAC failing and the CRC32 failing or when the MAC fails and the CRC32 passes, you would weaken the security of your system (and attackers could exploit this).

The only protection that the CRC32 could protect against is accidental memory corruption in your computer between calculating the CRC32 of the plaintext message and encrypting said message though the chance of that happening is also negligibly small.

In summary, if this is implemented poorly (e.g., the attacker can figure out that the CRC failed/passed even when the MAC failed), this can leak information.  If this is implemented perfectly, it would not provide any additional security as the keyed MAC is the part that would thwart a dedicated tamperer.


Why is malware not commonly written in Haskell?

[Disclaimer: not my area of expertise]

Yeah, I would assume that haskell is too high-level.

Things malware wants to, in order of priority: accomplish your task, fool anti-virus scanners on the target, resist reverse engineering and analysis in a lab.

The complex nature of compiled Haskell probably helps with the third, but probably makes the first two harder. For example, the following are common malware tasks that are probably difficult to accomplish in Haskell:

insert itself into another application or document such that it is still executable (virus behaviour)
obfuscate / encrypt its own string constants to avoid easy scanning of the binary
re-write its own code dynamically to change its fingerprint and fool anti-viruses
other evasion techniques
use and manipulate dlls it finds on the target machine
read / modify memory belonging to other processes
read / modify system data such as the master boot record

If you're at the level of sophistication where you're worried about reverse-engineering, I can't imagine that any compiled language is very attractive - you probably spend at least half your time working directly with assembly.


Is it safe to pay bills over satellite internet?

Satellite is not safe. Neither is cell data, wifi, or cable Internet. None of it is safe at the layer that you are talking. And that's not the layer that needs to be safe.

It's the data that goes over satellite (or wifi, cell, or cable modems) that needs to be secured. That's why we have HTTPS, that little green lock on your browser (it's gone now on most browsers and just grey now because HTTPS is pretty much everywhere).

So your choice of internet provider's media is not what's important in your situation. It's whether you use encrypted sites over that media.


Using Bitlocker and hidden volume feature of VeraCrypt together

Yes, it will work.

You can also use VC/TC containers created on a VC/TC-encrypted partition/drive with no problem whatsoever.


OpenVPN bridging vs routing: which is more secure?

Non is more secure, they are both equally secure, and many routing features provide VPN's, so it really does depend on features, but in terms of security, they are the same.


Danger of hidden html form uploading users local files without their knowledge

It's not possible for a web page to set the path of the file to be uploaded, the user has to select something or type it in.


Safari not showing GREEN lettering for EV SSL

Without seeing some kind of error or warning from Safari, it's hard to tell exactly what's going on.

My best guess would be that your page contains some non-http content that Safari's not happy about [link to StackOverflow post about this].

There seem to be some other things you can do wrong in the page code that Safari won't be happy about, for example using absolute references to content rather than relative [link]


What can I do if my bank thinks my date of birth is "known only to me"?

Find a bank with secure online banking, withdraw all your money and move it.

Make sure the teller knows why. Send a registered letter to the bank president telling him why it's a bad idea and why you've told all your friends and acquaintances why this is a bad institution to deal with online.

It's known as voting with your money. They don't secure it and only appreciate its removal from their system. Enough people do it, and they either sink or change.


does a public key work with all encrypted programs

If both email client supports S/MIME (Secure/Multipurpose Internet Mail Extensions) which uses the industry-standard X.509 version 3 certificates then yes, they are compatible.
Examples of such programs include Microsoft Outlook, Mozilla Thunderbird, Apple Mail and Mulberry Mail etc.

If your friend does not have a compatible email client, then he will have to manually use external toolkits like OpenSSL (example commands) to decrypt the encrypted S/MIME email.


How to disable the use of HTTP verb tunneling using HTTP headers or query parameters?

The example configuration should block the use of the HEAD verb, assuming that the server which has this configuration is receiving the verb at all (e.g. if you have a weird proxy setup which fakes HEAD requests by making a GET call, then dropping the body, it won't have any effect).
No, other headers will still be present - the server doesn't know that the other headers are treated as verbs by the application. If you want to prevent the use of other methods passed in this way, the best option is probably to remove the headers which the application can interpret as HTTP verbs. Depending on the application, this may break some functionality - I've seen applications which use this method of passing verbs for delete functions, or to allow modifications to records.

From your description, it sounds like the problem lies not in the use of HTTP verbs, but in how the application allows the actions they relate to to be performed, possibly with inappropriate permissions. It's hard to say without further knowledge about your application, but blocking a specific method of performing an action is likely to be less effective than blocking the action itself, within the application, unless appropriate authorisation is supplied.


Is it possible to use “cryptographic hash function” for “digital signature”?

Is it possible to use a cryptographic hash function for digital signature?

You can't use a hash function as a signature, but you -already- use a cryptographic hash function as part of procedure for a digital signature.

Let's first, mention some common reasons for applying a digital signature to communications:

Authentication
Integrity
Non-repudiation

Why we need Integrity?

If a message is digitally signed, any change in the message after signature invalidates the signature. Furthermore, there is no efficient way to modify a message and its signature to produce a new message with a valid signature, because this is still considered to be computationally infeasible by most cryptographic hash functions (see collision resistance).

What are these cryptographic hash functions?

A cryptographic hash function is an algorithm that takes an arbitrary amount of data input—a credential—and produces a fixed-size output of enciphered text called a hash value, or just “hash.” That enciphered text can then be stored instead of the password itself, and later used to verify the user. source

What's the procedure to sign a message?

source


Are there services to detect data breaches?

There have been quite a lot of data breaches in the past and I wonder how the companies got to know them. Were they only finding it in the news? Did individuals inform them?

Depends on the person who hacked them. If its someone who does it for fun/research they may contact the company and tell them about their findings.

What about small data breaches, e.g. if you have a user who has an account that was hacked but the exact same (email, password) combination is used in my service. Is it possible to get to know that and thus block the user?

You can check that user's email on  www.haveibeenpwned.com

f you have thousands of image/document files, is it possible to have something like a google alert to get a notification if the document has been shared (e.g. by creating a hash of the file)? Are there services providing that already?

Yes you can. There are services for that.


Xcode's git still vulnerable (CVE-2014-9390)? What's the best practice here?

Since the exploit is triggered only when you pull from untrusted repositories, and Apple has not released patches for previous XCode versions, you have two options:

Jump to the beta branch.
Do not pull from untrusted repositories. GitHub repos are safe, because they explicitly disallow repositories containing the exploit. Update internal git servers, and inspect unknown repositories before pulling.

Edit (3/10/15): As of today, upgrading to XCode 6.2 is an option! The new release fixes this option (see APPLE-SA-2015-03-09-4)


What evidence does a compiled file leave behind?

Yes it is true.
Both .Net and native applications (atleast those compiled by Visual Studio) contain an absolute path to a .pdb (Program Database) file when compiled in debug mode (which is usually the default). Since paths in Windows are usually of the form C:\Users\UserName\..., the path also reveals the malware author's OS username along with some information about the directory structure on their computer. It could also be possible to use it to deduce something about your nationality and/or locality. For example, if the path contains Chinese characters, it would be safe to say that the  author is Chinese (and  might live in China).
Portable executable headers also contain a TimeDateStamp which indicates the time at which the file was created/compiled. This could be used to roughly infer the possible time zone(s) in which the malware author resides (atleast for professional malware developers who can be expected to work during normal working hours. Amateur developers probably work at unpredictable hours).


Does a company need to follow some methodology (e.g. Scrum) to be PCI DSS compliant?

Note: Not a QSA, just have some PCI experience

The Requirement you are interested in is 6 - "Develop and maintain secure systems and applications"

The short answer is no - you cannot be compliant with just documentation of vulnerability and bug fixing.  You must document policies for (probably not a complete list) :

vulnerability finding procedures
vulnerability assessing procedures
vulnerability information assessing (ie, who do you trust about vulnerabilities)
third party patching - ie, that you apply security patches in an appropriate timeframe
that you have "industry-standard" development processes (this isn't prescriptive as to what you need, but you must demonstrate you have a standard that is at least as informative as scrum or the pmbok or kanban or what have you)
that information security is included throughout the lifecycle (basically, you are worrying about security at design time, at implementation time, at testing time, at rollout time and during maintenance/operation of the software)
that all these processes and policies are written down and known by all developers
that you have policy to prevent dev accounts and data from reaching prod
that you have policy to ensure that one person can't write and promote the code (must have two sets of eyes on every change)
that you have policy ensuring that code review checks that all code meets secure coding guidelines
that management examines code review artifacts and signs off that appropriate review was done
that dev and test environments are different than production, with separate access controls
that controlled information from production isn't used in development
that software change controls are robust and documented
that changes are reversible
that all developers understand/have been trained on the OWASP Top Ten mitigations and other standard secure code techniques / information
that you scan public facing web applications regularly with scanning software

Wow. That got longer than I expected.

tldr; no - you need to do much more than document your bug and vulnerability fixing.


How can I block hits to Youtube using iptables?

Attacking this problem at the DNS layer is going to be problematic... better to attack the problem at the application layer.  Parental control software is designed specifically for this use case, and finding lists of software with reviews is easy.  A good package will also handle nuances like blocking sites during school hours but permitting access after school.


Password and Generated number - How does it work?

There are several methods for such tokens. One of them is HOTP: the token and the server both share a common secret value, and a counter; from the secret and the current counter value, a one-time password can be generated (the token displays it, the server verifies that the entered password matches that which was expected).

Some tokens also include the current date and time in the process, so that the one-time password is also limited in time: this supposes that the user pushes the button on the token and immediately enters the displayed password (the use of time prevents the user from generating some OTP in advance and writing them down on a piece of paper). The usual standard for that is TOTP.


Why don't web apps use custom security questions?

The main problem with security questions is how easy it can be to obtain the answers, no matter what the actual question is.

You've raised 2 examples which sound equally as bad to me:

Favorite car: Can be extremely trivial to obtain. What if you know the person's username which he also uses on a car forum which turns out to display what his favorite car is?
Mother's maiden name: We're in an era where people mindlessly share personal information through social media. Depending on the system, it could be very easy to figure out the person's name and a quick browse on their Facebook page could reveal this information.

Also, these are highly vulnerable to social engineering attacks. Let's take an online multiplayer game for example. A user could casually ask you questions and then without noticing, you could be answering questions that would allow the user to recover your account.

Finally, letting the user decide the question is a huge responsibility that he most-likely wouldn't be aware of. You can't expect the user to enter a question that nobody will ever know the answer of when passwords such as Password1 can still be seen in the wild.

To conclude

For these reasons, it is hard to justify the use of security questions and would suggest to implement email recovery instead, which requires the attacker to either control your email address or successfully conduct phishing to recover your password.


First, there is no "real SHA-3" yet. In a few months, NIST will publish a specification which will define unambiguously what SHA-3 is. Unless there is a big blunder somewhere, we can predict that SHA-3 will be bit-to-bit compatible with the specification of Keccak as submitted for round 3 of the competition.

Then there is no reason to replace SHA-2 with (future-)SHA-3: neither scientifically (SHA-2 is not broken, far from it; and, for performance, Keccak is not terribly better than SHA-2, and often worse, depending on the architecture), nor administratively (the NIST people themselves posit that there is no need to replace SHA-2 with SHA-3).

There are reasons to replace MD5 and SHA-1 with SHA-2 (or SHA-3 in the future) but these reasons were already valid last week and you should already be doing it.

Algorithm agility is an important quality of protocols -- but that's a question of protocol design. People who are qualified to design security protocols already know it, and the other should refrain from designing protocols.


Career advice - Is it possible to get a security job without formal education? What can compensate for the lack of it?

It greatly depends on where you live and what your expectations are. If you are looking for a penetration tester job, yes you will have a chance. The field is in general very understanding for one's past but you will have to prove yourself very often prior getting hired by solving some sort of challenge. Some companies even offer internships. With regards to the mentioned certifications, I would suggest you do the OSCP. Forget about CEH. I even know people who sort out your CV and not return to you if you list it! It has a bad reputation.

My advice for you:

Reserach the pentest companies where you live and if your
countries market has a specific preference for a certification
Join DEFCON, OWASP chapters in your area
Attend conferences - especially smaller ones, don't bother Las Vegas for now, that are close to you and start networking!
Write blogs, read blogs, blog! Make yourself a profile
Network, Network, Network You're more likely to land a job if you get internal referral in your position. But you also have chances without.

Good luck and welcome to the most amazing industry on this planet!


Is it secured to store the encrypted key in the database (encrypted by other cipher)?

If I understood you correctly, you want to continue using the old key, which remains hard-coded, but only use it to encrypt AES keys, which are then used to encrypt and decrypt your data.

This does not improve your security. The vulnerability in your old design is that the key and IV are hard-coded. If you encrypt the new key with the old key, that adds an extra layer of complexity (because you need to handle multiple keys) but it doesn't actually fix the issue you had (hard-coding a key). If you want to do key rotation, as you say, you should replace the old key with the new one after re-encrypting the data you used to encrypt with the old cipher.

As far as the IV goes: from a cryptographic standpoint, as long as IVs are unique per encrypted text, these are public. For example, in CBC mode, the IV is just the first input that you XOR onto the plain text; for all subsequent blocks, the cipher text of the previous block is used for that. What matters is freshness.

Alternatives to hard-coding

Storing your key in a database is better because you at least have the ability to change the key later. If you properly protect the database (i.e., password protection and encryption), that could be a reasonably secure solution. However, it is likely easier to use an existing library that stores your key in a file, protected with a passphrase. That would mean that to access the data, your logic would consist of:

get the passphrase
extract the key from the file using the passphrase
discard the passphrase from memory
decrypt the data using the key, encrypt and write any new data
discard the key from memory

You can likely get all the passphrase stuff done using a library. I recommend you open a second question if you've got more questions about that topic.


Your mails are probably being marked spam because the SMTP plugin that you're using is almost certainly used by other users, who other Google users mark as spam. Now when your mail is sent from the same IP, it goes straight into the spam folder. To combat this, have your plugin send the mails to your own SMTP server and then mail then from there. That should do the trick.

A plugin that helps with this: http://wordpress.org/extend/plugins/wp-mail-smtp/


I do not think that the gratuitous have something to do with MITM attack prevention. Hosts usually send gratuitous ARP packets when they join the network to notify other host about their presence and their IP/arp info (even if they have not received an ARP request). Host send such packets also in case their interface comes up and in some other cases.

Some switches have a built in protection against ARP poisoning attacks. CISCO calls this technique "Dynamic ARP Inspection". In short, before forwarding an ARP packet, it verifies if the advertised IP address was really issued by the DHCP server to a host with the particular ARP address.

If you want to sniff all packets on a network segment, you will have to have an network/wifi adapter that supports promiscuous mode (and that mode should be enabled). On a wired network, the network switch will of course not forward all traffic to you, but only traffic that is sent to your MAC address. Because of that, it would be a good idea ARP poison the network and force the switch to forward more traffic to you than it should.

Regarding your last note, I would suggest you to try an ARP scan with nmap:

nmap –PR target


Can my employer see the actual video chat if I use Facebook messenger on work WiFi?

I will disagree with the other answers here:

Going directly to your specific scenario: You are using the company Wifi, so they control it and could capture its traffic. However two other important things are mentioned: you are using your personal device and acessing a service outside of the company that uses SSL/TLS. So they capture encrypted traffic.

Since it is your personal device and a service outside the company control, it is NOT trivial to sniff this TLS/SSL traffic. SSL sniffing requires control of your device trust anchors (trusted CAs) or control over the service endpoint, and that should NOT be the case on your personal iPad. One can only sniff an SSL connection using an MITM attack, and to have a MITM attack without a lot of warnings poping up (I guess the Messenger app would not even show a warning, would just not work) one needs to be able to inject trusted CAs on your device. That is common on company managed devices, but would not happen in a personal device (not without your explicit approval, at least).


How to prevent expired cookies from maintaining accesss?

How do sessions work?

Before you can understand the issue, you need to have an understanding of how sessions work.

The most common way to manage sessions is to send the browser a cookie with a random, unpredictable value when they log in, and map it to some data on the server:

User POSTs login info
Server validates login info, creates random string 2c64279f045bcb64ea8cd4d576514545, maps it to some data:

2c64279f045bcb64ea8cd4d576514545: {userId: 123, username: "johndoe", otherdata: ...}
Server tells browser to store 2c64279f045bcb64ea8cd4d576514545 as a cookie that will eventually expire
The browser sends the cookie with every request to the server, so the server can see who is making the request

How does session expiration work?

Since the cookie data is used as a lookup value on the server, just expiring the cookie isn't enough. Anyone could copy the value and the server would have no idea that it should have expired. Session expiration must happen server side. How this is done depends on the language and framework you are using. I've not personally used .NET, but this may be relevant.


Kerberos is essentially just for authentication, not authorization; however the ticket data structure has a field for authorization info, in case an implementer wants to encode such information in a credential. Unix implementations of Kerberos have mostly just left this field unused, but Microsoft chose to use it, and embeds a “privilege attribute certificate” (PAC) in tickets it issues containing security information about the AD account to which the client Kerberos principal corresponds: group memberships etc. This goes not just in the TGT, but in any ticket issued by AD. The advantage of this is that servers which receive these tickets immediately know these user attributes in a trustworthy fashion, and do not have to then query AD separately to discover them. A down side is that if things like group memberships change, a user needs to get a new ticket for that to be reflected (and are usually told to “log out and log in again” to accomplish that). And of course, if you remove someone from a group, that is not fully effective until all the user's tickets have expired.

  My goal: To help identify the biggest offender that's causing the TGT ticket to be larger than the max limit ticket size set in our Apache server.

Apache doesn't have a “max ticket size.” Kerberos authentication happens in HTTP headers exchanged by the client and server, and the service ticket is encoded in them and so grows as the count of a user’s group memberships increase. Apache has a default size limit on headers which is low compared to possible AD ticket sizes (8K). You can just increase it with the Apache LimitRequestFieldSize directive.


XSS typically affects locations where a user can type in input, ie. comment fields, username / password entries, even the url can be susceptible to XSS.

There are two main types of XSS, reflective and persistent. Reflective affects the user that typed in the commands, and persistent affects anyone that visits that page. Both are the same except for the fact that persistent needs to be stored on the server somewhere, in a comment field is a common one, so that it can be loaded by other users when they visit the page.

The best thing to do is create some kind of input validation that removes all special characters or any other type of character that you don't want on your site. Regex are a common and simple method to remove and sanitize your users input. I'll write some code below in PHP that you can use to sanitize input:

Method 1

<?php
    function clean($string)
    {
        $string = str_replace(' ', '-', $string);
        $string = preg_replace('/[^A-Za-z0-9\-]/, '', $string);
        return preg_replace('/-+/', '-', $string)
    }
?>

Method 2

PHP has built in functions that you can use to sanitize input as well.

if (isset($_POST['submit']))) {
    $sanitized_input = filter_input(INPUT_POST, 'username', FILTER_SANITIZE_ENCODED, FILTER_FLAG_STRIP_HIGH);
}

As for the testing of whether the page is still vulnerable, I usually spring up a WAMP / LAMP server and just run the page locally, since it is the easiest and fastest method for quick testing and validating (for me).

If you want some more info on this leave a comment below and I can link you some material for further reading, or answer any more questions you have.


You route relevant traffic through your IDS yes. Latency will depend on your device's performance.
VLANS are secure if implemented correctly. Make sure to also use 802.1x (PNAC) to authenticate devices at layer 2. Make sure you do not start routing between your VLANS (unless appropriate)
Depends what type of VPN you employ, layer 3 or layer 2 VPN. Make sure that you also use two-factor authentication on your VPN. It's not overkill in my opinion as you are trying to prevent access to your business critical data and services in a controlled manner. Make sure you also appropriately log all connections.
This can be done by a point-to-point tunnel. If the machine is available on the internet you could also perform certain checks from the WAN using a separate, dedicated monitoring machine (ICMP, HTTP,...). You should only allow management protocols like SSH and SNMP to be used from your point-to-point tunnel. Your monitoring machine can check if the machine is connected to the WAN with the first checks and then can see if all services are running smoothly. This is also to avoid a scenario where your monitoring server starts reporting your machine is critical whereas your VPN tunnel just went down (which is also critical but not necessarily device related).
Always use an AV. Remember that the ILOVEYOU virus was a VBS script which was executed by a user. You should not be using your servers to surf the internet, download or open files sent to you by unknown people. You should only execute already tested scripts and binaries which can be trusted. (trustworthy source). Make sure to also use EMET.
This is off-topic. If you are serious about your business you should invest in a vulnerability scanner like Nessus.


The history of thumbnails (or just a previous thumbnail) is embedded in an image file?

Jpeg files can contain Exif data, which can include a thumbnail. Theoretically, it seems it would be possible to store more than one, but I don't know of any program that does it, nor of a program that would read it.

What is likely to have happened in your case is that the program you used to crop the image modified only the main image, without modifying the embedded thumbnail.

exiftool can be used to read or replace Exif data, including the thumbnail. As show in the documentation, exiftool -b -ThumbnailImage image.jpg > thumbnail.jpg can be used to extract the thumbnail from a jpeg, exiftool '-ThumbnailImage<=thumb.jpg' dst.jpg to replace it. If you want to completely remove the embedded thumbnail, you could use exiftool -ThumbnailImage= dst.jpg.

Note that exif data can contain much more than a thumbnail, as exiftool -a -u -g1 a.jpg will show you.


WAF logs show plaintext password and login in a POST header sent via HTTPS

tl;dr

You're probably seeing plaintext information in the event logs because the WAF decrypts the data as part of its analysis.

  How come the POST information part wasn't encrypted, since TLS seems
  to be used

To be sure we'd need more information about your network setup, but I'll take a guess (as in Serge Ballesta's comment):

The information was encrypted (by the client browser), but it was decrypted by some appliance to better analyse it.

Web application firewalls usually have the ability to not only intercept HTTPS traffic, but to decrypt it, because otherwise they could not meaningfully analyse the traffic. This is called HTTPS inspection. Incidentally, the Imperva WAF (called Imperva SecureSphere Web Application Firewall) happens to offer HTTPS inspection, so most likely it decrypted the traffic itself.

Note that HTTPS inspection is a powerful, but dangerous tool, because it breaks the end-to-end nature of HTTPS, so it should be deployed with care. But that decisions seems to have been taken already in your case...


How important is the JWKS endpoint in OpenID Connect?

OpenID uses JWTs to provide access and ID tokens. These JWTs tell us everything we need to know for those tokens. However, you need to trust the JWT. And to do this you must have the public key available from a source other than the JWT. You can:

Get the public key from the JWKS (.well-known/jwks.json) endpoint.
Get the public key from some other trusted location. This other location can be a database, configuration file, something reasonable.

From the perspective of validating the token, I have not heard of any issue with validating a JWT against a public key found elsewhere.

However, you want to be able to rotate your public key if need be, since the corresponding private key is critical to securing the JWT tokens. If you take option #2, you risk having public keys scattered all over the place that would make it harder to update all the public keys. So if you take route #2 you want to be sure you can rotate your keys.

Also, if the OpenID Connection provider is outside your control, they could change their keys and you wouldn't necessarily know.

The Signatures and Encryption section of the OpenID spec says:

  The OP advertises its public keys via its Discovery document, or may supply this information by other means. The RP declares its public keys via its Dynamic Registration request, or may communicate this information by other means.


HTTPS client certificates for server-to-server

Actually, there is an often unused (at least on the web) optional part of SSL/TLS that allows for client authentication. It is generally not used on the web because the server doesn't really care if the client is who they say they are - they just need to have the proper credentials. Additionally, imagine the nightmare of having to verify every client in the world to a certain computer, IP, Domain, etc. I don't even know how it could work. It would be sort of a global internet ID card/cert - a pretty scary idea if you ask me!

Wikipedia has a decent walkthrough here, that explains how the clinet authentication works: http://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_TLS_handshake

You can compare that to the basic handshake for the more common way we see SSL/TLS handshakes go down.

So, the answer to your question is definitely "yes" with the understanding that one of your servers is still acting as a "client" in this scenario. That last part is just semantics though.


mdk3 is not included in aircrack-ng suite at the moment, but it seems they started to collaborate some time ago. Look at this: https://svn.mdk3.aircrack-ng.org/mdk3/docs/Documentation_incomplete.html

Maybe in the future could be integrated. In fact, the new MDK3 uses the osdep injection library from the www.aircrack-ng.org project.

The difference between aireplay-ng (included in aircrack-ng suite) and mdk3 is basically that mdk3 would be sending both disassociation and de-authentication packets, where aireplay-ng only sends de-authentication packets.

Regarding how it works... basically, mdk3 works by exploiting weaknesses in the IEEE 802.11 protocol.

It has a lot of TEST MODES:

b - Beacon Flood Mode

Sends beacon frames to show fake APs at clients. This can sometimes crash network scanners and even drivers!

a - Authentication DoS mode

Sends authentication frames to all APs found in range. Too much clients freeze or reset some APs.

p - Basic probing and ESSID Bruteforce mode

Probes AP and check for answer, useful for checking if SSID has been correctly decloaked or if AP is in your adaptors sending range SSID Brute-forcing is also possible with this test mode.

d - Deauthentication / Disassociation Amok Mode

Kicks everybody found from AP

m - Michael shutdown exploitation (TKIP)

Cancels all traffic continuously

x - 802.1X tests

w - WIDS/WIPS Confusion

Confuse/Abuse Intrusion Detection and Prevention Systems

f - MAC filter bruteforce mode

This test uses a list of known client MAC Adresses and tries to authenticate them to the given AP while dynamically changing its response timeout for best performance. It currently works only on APs who deny an open authentication request properly

g - WPA Downgrade test

Deauthenticates Stations and APs sending WPA encrypted packets. With this test you can check if the sysadmin will try setting his network to WEP or disable encryption.

A Proof of Concept about how to test it, here.


PHP max_input_vars security expectations

The vulnerability is about hash collisions and not necessary about the size of the request.

So yes setting the directive to a higher value is probably not a smart idea (even when you are limiting the post_max_size or any of the other related directives).

Also if you need to set it to something like 100000 you should really reconsider what you are doing in most cases.


How likely is a collision using MD5 compared to SHA256 (for checking file integrity)?

There seems to be some confusion about the capabilities of a collision attack.

Two of the properties a cryptographic hash must have are collision resistance and preimage resistance.

If a hash is collision resistant, it means that an attacker will be unable to find any two inputs that result in the same output. If a hash is preimage resistant, it means an attacker will be unable to find an input that has a specific output. MD5 has been vulnerable to collisions for a great while now, but it is still preimage resistant.

What does this mean for integrity?

If you trust that the party that originally hashed the data to provide you with the integrity check is not malicious, and they did not allow anyone to modify the data beforehand (any part of the data, even if 2 images, videos, or pdfs look identical they can be vastly different), then MD5 should be sufficient to verify integrity, and SHA-256 shouldn't offer much more security (barring any future attacks on MD5's preimage resistance).

If an attacker may have been able to make any modifications to the data (even seemingly benign modifications), then SHA-256 will be more secure, as with MD5 the attacker could have crafted a malicious file with the same hash.

Are these integrity checks useful?

In many cases, not really. If you're downloading the file over HTTPS from the same website providing the hash value, then you're already benefiting from the MAC TLS uses for authenticity checking, so a MitM will be unable to change the file in-transit. If someone is able to modify the file on the site maliciously, they can also modify the hash.

One case where it does make sense to verify an MD5 or SHA-256 hash for a file is if you download the file from a mirror and check the hash against one provided by the original trusted site.


Does the modulus of a TLS certificate uniquely identify the client?

If we are talking about RSA, then the public key is, nominally, the combination of:

The modulus n
The public exponent e

while the private key is the knowledge of the prime factors of n (traditionally, n is the product of two prime factors p and q of similar size). Formally, the private key is really the combination of the modulus and the private exponent d, but if you know n, e and d then you can recompute the factors p and q.

Therefore, if two distinct public keys share the same modulus (hence the same factors), then they have the "same" private key, in the sense that anybody who knows the private key for one of the public keys also knows the private key for the other public key. Thus, the two keys are "the same" or at least correspond to the same private knowledge.

So you can, indeed, claim that the RSA modulus alone uniquely identifies a private key, hence (presumably) a private key owner.

However, you must take care that while a private key is normally known to a single owner (otherwise it is not really "private"), a single person may perfectly own several key pairs. In particular, when a certificate is "re-issued", this really is a brand new certificate, which may or may not contain the same key. This depends on the CA procedures: some will reissue certificates with the same public key, while some others will insist on the generation of a new key pair. You cannot reliably assume that when a server "renews" its certificate, the new certificate will include the same public key.

Also, the notion of "modulus" is specific to RSA, and does not apply to other pubic key types, in particular EC keys (used e.g. for ECDSA). If you want to identify things by public key, you are encouraged to simply use the whole public key, as encoded in the certificate.


Certificate chaining:Intermediate Certificate Authorities

With standard browser, it will most likely not work. However, nothing prevents such behavior with standalone applications (see Thomas Pornin's answer to SSL root certificate optional?), in such case one would talk of a trust anchor, ie. it is not a root certificate (it is not self-signed) but is nevertheless a trusted certificate usable as starting point to build the certification chain.


Why do browsers probe and fallback (or, why SSL_MODE_SEND_FALLBACK_SCSV)?

Client software that is susceptible to downgrade attacks is defective, in the sense that it purposely does things outside of the standard in order to support server software that is defective.

Normally, the client announces (in the ClientHello) its highest supported protocol version number (e.g. "3.2" to mean "TLS 1.1") and then the server responds (in the ServerHello) with the protocol version that will be used for that connection. Therefore, the theoretical behaviour when a recent client talks to an old server is the following:

Client says: "I support up to 3.2".
Server thinks: "Mmh, I have no idea what SSL 3.2 may be, but I know SSL 3.0 and 3.0 is less than 3.2".
Server responds: "We will use 3.0".

However, in some rare cases in practice, old server software is not only old but broken; and things go that way:

Client says: "I support up to 3.2".
Server thinks: "OMG 3.2 I HAVE NO IDEA WHAT THAT IS I MUST COMMIT HONOURABLE SEPPUKU". Server closes the connection abruptly.
Client thinks: "Mmh, the server broke. Probably an old piece of junk. I must use patience when I speak to the elderly".
Client reconnects and says: "I support up to 3.0".
Server responds: "We will use 3.0".

When things go that way, the hash that is computed over all handshake messages and included in the Finished messages does not include the fact that the client could have used a newer protocol. By reconnecting and using an artificially lower announced version, the client prevents the downgrade detection system from working. We can say that the problem occurs because the clients don't act as they should, but they do so because there are deployed servers that are even more broken. It can be hard to unambiguously lay blame here.

Attackers who want to force a protocol downgrade abuse that system by killing the first connection with a well-placed RST packet, so as to simulate a senile server that cannot tolerate any of this newfangled talk about a protocol version other than 3.0.

The TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks extension, currently in draft, is a method for sneaking in the handshake message the information that the client really supports better than SSL 3.0, in a way that won't make old servers scatter their electronic brains on the floor; it takes the form of a special cipher suite identifier (it is based on the idea that even old broken servers will not go berserk when the list of supported cipher suites includes one that they do not know). Of course, the mechanism brings any protection only if both the client and server are aware of it (the client must put the special identifier, and the server must recognize it and say to itself: "how come we are doing SSL 3.0 if the client knows a newer version? This is fishy...").

Another view on the subject is that if SSL 3.0 is weak and should not be used at all, then the only sane practice is to reject it altogether. You need a protection against downgrade attacks only if you are still ready to use SSL 3.0 in case the server truthfully supports nothing else. If you fear the consequences of using SSL 3.0, then you should never accept to use it. This is considered as potentially extreme; a smoother compromise may be, on the client (browser) side, to maintain an explicit list of servers for which SSL 3.0 will be tolerated. Such a list, configurable by the user himself, combines possible tolerance of a few legacy systems, and a healthy dose of finger-pointing at the systems whose misery should have been ended long ago.

Edit: see the comments there; this is a discussion between Firefox maintainers where they discuss exactly the consequences of dropping SSL 3.0 support altogether, and various alternatives.


Well, there could be many reasons (sorted by order of probability):

The XML parser is running inside Docker: If it's running inside docker, there's no /etc/passwd file nor /etc/hostname file to leak.
The XML parser does not have enough privileges to read those files.
The files you're trying to leak are in a different encoding than expected (Expected UTF-8, got UTF-16).
The files you're trying to leak is corrupted.
The files you're trying to leak is empty.

For all of the previous cases: instead of returning a nasty error, it returns an empty string, hence why the x parameter in the GET request is empty.


Injecting information in a web page (Gmail). Does it raise security problem?

1.) Does it raise security problems to inject the plain text in the web page ?

Plain text is just text... there are no security impacts unless you start injecting code wich actually gets executed server side.Besides, what you are describing is client-side encryption/decryption. As a result, you'll end up with either plain text (=decrypted) or an block of "random" chars (=encrypted, guess base64-encoding after encryption and bas64-decoding before decryption will be safest when thinking email transfers)

  2.) Does the web page (so Gmail) can detect such injection ?

As Google changes/updates it's code on a rather frequent base, that's hard to tell. Currently it would not... yet that might change any second (depending on when Google pushes a next minor update online). Theoretically, it is possible for Google to implement a rather simple javascript routine that looks for modifications of the page itself, or of child elements of the document (like the textarea). Practically, it isn't currently done... but as I said: when Google changes it's code, you could be in trouble and your extension void before it's really live.

  3.)Is it vulnerable to a Man in the middle attack ?

If with "it", you mean your client-side encryption/decryption... no, as it happens CLIENT-side before sending any data anywhere.

If with "it" you mean "email traffic" when sending the data after encryption, you should know that — generally — email traffic "can" be vulnerable to MITM attacks. But as Google mail tends to enforce the use of SSL, I personally regard it to be safe from MITM attacks when users indeed keep SSL enabled at all times.

Talking about vulnerabilities, I would like to point you to two other things you should consider:

Depending on the crypto you are going to use, the way you are going to implement things can and will have an important impact on potential (crypto-related) vulnerabilities to consider.
Client machines of sender and/or receiver may be compromised — intercepting and transferring the decrypted data using malware like trojans.
Sending blocks of encrypted data via email can and most probably will put you on the radar of whatever governmental agency might be interested in the contents of such "encoded messages". It's been known for years, but recent news related to #prism reminded us all that "they" are actively parsing traffic like emails when something looks suspicious. I guess I don't have to explain that using cryptography isn't saying "I've got nothing to hide", but rather the opposite.

Last but not least, remember that - when it comes to software development in general - there are restrictions on the import of cryptography and there are even more restrictions related to the export of cryptography and export of cryptography in the United States) related to cryptographic implementations. Depending on your residence, these might have an impact on the product you are planning to create. Currently, many countries, notably those participating in the Wassenaar Arrangement, have similar restrictions. So, be sure to read the docs that come with the cryptographic algorithm(s) you are planning to use or you might face other kinds of trouble later on.


Restrict user login to a specific machine

You would typically install a client certificate on each user's machine and require it for access to the web site.

This of course requires the machine's OS be locked down heavily to ensure that the client certificate cannot easily be moved.

If this is not possible, an alternative would be to use a hardware dongle that is physically attached to the machine in a non-removeable fashion. (And of course you'd have to physically attach the machine to the cubicle.)


Why does printf() vulnerability require 4-bytes of junk data? - “Hacking: The Art of Exploitation”

I guess it depends and varies on the compiler and the system you are running on.

For example what worked for me on the test code you supplied is: (on a ubuntu 32 bit machine)

  \x30\xa0\x04\x08\x31\xa0\x04\x08\x32\xa0\x04\x08\x33\xa0\x04\x08%154x%4$n%17x%5$n%17x%6$n%17x%7$n

the first 16 bytes are the addresses I want to inject to: 0x0804a030, 0x0804a031, 0x0804a032, 0x0804a033 - since the address of test_val in my case is 0x0804a030.

Then the %154x tells printf to pad the output with 154 chars. Since 16 chars were printed so far 154 + 16 = 170 = 0xAA

Then %4$n tells printf to write the value into the address in the 4th paramter passed to printf. This value is found by trial and error in order to located in which offset in the stack your input is found and make printf use it as the target address. You can inject AAAA%p%p%p...%p in order to find where the 41414141 value is located and then you know your offset. in my case it was 4.

The rest just adds 17 = 0x11 chars in order to increment the injected value to the wanted value and make printf write it to the next pointer, in my case 5, 6 and 7

I guess the reason the author needed 4 extra bytes in his case was the way the compiler handled the parameters on the stack in his case. Maybe they were supposed to be separated by 4 bytes and hence he could not inject the addresses without padding them with 4 bytes in between.

Had i injected the string with the JUNK 4 bytes I had to later my input to:

  \x30\xa0\x04\x08JUNK\x31\xa0\x04\x08JUNK\x32\xa0\x04\x08JUNK\x33\xa0\x04\x08%142x%4$n%17x%6$n%17x%8$n%17x%10$n

changing the target pointers to 4, 6, 8, 10 since in 5, 7 and 9 the JUNK bytes were found.

Here is a linkt o an excellent blog post on the matter: http://codearcana.com/posts/2013/05/02/introduction-to-format-string-exploits.html


How difficult is it to modify an ISO image and still have the old md5 check sum?

It would be difficult to the point where to seriously suggest it even remotely possible is verging on lunacy.

There have been some demonstrations of theoretical attacks against MD5 wherein the "attacker" could create message data intended to yield a predetermined MD5 hash. But this is miles and miles away from adding a non-jibberish file to an ISO and having it give the same hash.

A much more likely attack scenario would be the MitM altering the page that lists the MD5sums before it gets to you so that you see the attacker's hash rather than the real one. However unlikely this may be, here are the hashes for your comparison:

  ubuntu-11.04-desktop-amd64.iso 7de611b50c283c1755b4007a4feb0379

  ubuntu-11.04-desktop-i386.iso  8b1085bed498b82ef1485ef19074c281


How commonly are SSL/TLS or S/MIME used by e-mail providers?

TL;DR - Without end-to-end encryption, such as S/MIME or PGP, being supported and used by both sender and recipient, it's a fair presumption that your e-mail has been transmitted or stored in the clear, or otherwise readable by a third-party, somewhere along the way.

I think you have some mis-conceptions of what S/MIME and SSL/TLS are, or how they work.

S/MIME is a mechanism for providing end-to-end message security.  Encryption, digital signature, decryption, and signature verification are all done at the endpoints by the client software.  The intervening e-mail servers and service providers have nothing to do with this, as the messages get passed along just like any other.  Further, and perhaps most importantly, S/MIME must be supported by both the sending and receiving clients in order to work.  This is beyond the ability of any single e-mail provider to ensure.

That being said, I'm not aware of any common freemail provider (i.e.: GMail, Yahoo, Hotmail) that is currently facilitating S/MIME in their browser-based clients.  Certainly none of them are, nor would they want to be, enabling it as a default.

The reason this cannot work at the service provider level is because of the requirement for both endpoint clients to support the protocol.  Since the service provider of the sender has no control over the client software used by the recipient, enforcing S/MIME use on outbound messages would result in many (if not most) recipients not being able to read the sender's e-mails.

The only conditions under which S/MIME will work are when all participants in the e-mail conversation have S/MIME-compatible clients, and everyone has (and has verified) each others' public keys.  Again, this is not something that any individual e-mail service provider can effect.  They may conceivably be able to facilitate this between their own users, but they do not have the same power to protect e-mails going to/from external endpoints.

SSL/TLS are technologies commonly used to secure communications between clients and servers and from server-to-server.  However, here we again run into a similar situation as with S/MIME - both parties to the conversation must support it.  While some service providers may do this, no service provider can guarantee you that SSL/TLS will be applied to every message you send because they do not have control over what the receiving server is configured to support.

To address your concerns more concisely, point-by-point:

None of the above use S/MIME.  While it would be a nice feature for them to support in their web clients, it would be infeasible for them to guarantee that it will work for all recipients.  You can get around this to some degree by using your own e-mail client with S/MIME support, instead of using the web interfaces.  However, again, this will only work where you have coordinated this with your intended recipients.
SSL/TLS is commonly used to protect the web sessions by which e-mails are composed, and the client connections by which they are sent.  It's also used to protect server-to-server communications along the way, but no service provider can guarantee that every recipient's e-mail servers or client will support and maintain that protection along the way.
Many providers do use SSL/TLS, but you should check with yours yourself if you're concerned.  Again, though, this cannot guarantee that your e-mail is protected through transmission and storage every step along the way to every recipient.
Any time you are sending/receiving e-mail which is not protected by S/MIME, PGP, or a similar end-to-end encryption solution, you must assume that the message has been transmitted or stored in the clear, or in another form readable by a third-party, somewhere.

The last point touches on an issue I've not yet addressed - e-mail storage on the server.  All e-mail service providers, by the nature of their service, must store e-mails exactly as they were received or by using some form of encryption that they themselves can reverse.  Otherwise, they will not be able to forward the e-mail on in a readable format to others or display it to you in your web browser.  If you're not using end-to-end encryption, that means your e-mail is being effectively stored in the clear.  This leaves it vulnerable to malicious insiders, or anyone who manages to hack into your e-mail account or the server's database.


Is it safe to redirect to URL parameter without filtering?

The short answer
No. This is not safe, and should not be done. In fact, this is the last one of OWASP Top 10:

A10. Unvalidated Redirects and Forwards
Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.

Phishing and spreading malware
An attacker could craft an URL to redirect to any page they want, and then spread it everywhere:
http://trusted.com/index.php?redirect=http%3A%2F%2Fmalicious.com

The malicious URL could be obfuscated to avoid detection by the user by URL encoding all character so you get a string like %68%74%74%70%3A%2F%2F%6D%61%6C%69%63%69%6F%75%73%2E%63%6F%6D.
Now a user clicking what looks like an ordinary safe link to your site might end up anywhere:

On a site looking exactly like yours, asking for username and password. Boom, accounts stolen.
A site spreading malware by drive by downloads. You could try to claim this is not your problem, since it is technically not your site spreading it. I am not sure the victim would agree.
Just anything. Do you want users clicking links to your site and ending up on illegal or NSFW or NSFL content?

If this is done after the user logins, as you hint at in the question, it is even more dangerous since actually being on your page entering the credentials strengthens the users belief that he is actually on your site. It would be so easy to serve an "incorrect password, try again" type of page after the login.
Header injection
As already stated by Steffen Ullrich in his answer to this question and me in this answer to another question, on PHP versions older than 5.1.2 this could be used for header injection.
What to do instead
Whitelisting or validation
As so often, the solution is to whitelist. Here is an PHP example:
$param = $_GET["redirect"];
$allowed = array(
    "index" => "index.php",
    "blog"  => "blog/index.php",
    // ...and so on...
);
$redirect = isset($allowed[$param]) ? $allowed[$param] : "index.php";
header('Location: '.$redirect);

This will be tedious if there are many pages you want to be able to redirect to. Depending on what your URLs look like, you could validate URLs for your own site. For instance if they are on the form http://trutsted.com/?pageid=1234 you could accept only the pagied to redirect to and verify that it is in fact numeric.
Referer check
If you only want the redirect links to work from within your own site, you could check the HTTP referer heading of the request. This might run into some issues if you serve your site over both HTTP and HTTPS, since if you link from a HTTP page to an HTTPS page the referer header will not be sent.
Here is some example code:
$headers = apache_request_headers();
$referer = isset($headers['referer']) ? parse_url($headers['referer'], PHP_HOST) : "";
if($referer == "trusted.com") {
    //Do the redirect. If you want your code to be safe on old PHP versions,
    //you will need to filter out newlines or just URL encode the URL.
}
else {
    //Inform the user of the problem or just redirect to your index page.
}

More reading

OWASP cheat sheet on unvalidated redirects. (One of the examples on how not to do it here is alwmost identical to how you did it in your question.)
Troy Hunt has a great piece on this topic.


NTFS Meta datas

Considering ntfs, if you overwrite a block with any data, this block is irreversibly overwritten but,

NTFS hold name, size and some other information (meta data) in another place than data. So overwriting data won't hide this.
If the data written in place is totally random or zero only, origin of data won't be surely determinable.

Low level

If you do a full overwrite of your disk or partition, many times with random data, than finally with zero, your disk will seem cleen as never used..

wikipedia: Zeroisation

But if you wanna really know what's happens with a disk, you may try to use forensic hardware, like white room and magnetic force microscope to reconstruct some generation of data

wikipedia: Data remanence

SSD and flash

Warning! This kind of material work with a limited life time. this mean: each generation of data would use another physical space on flash memories!

Shredding wild just reduce life time, but won't hide anything for forensic labs!.

wikipedia: Flash memory