Session Cookie Stealing Protection I am looking at how to secure a web site against getting its session cookie stolen. These are the controls that I know are widely known/used:

HTTPS Everywhere
Only use a securely created random string for the cookie value
Mark the session cookie Secure and HttpOnly
Change the session cookie on login

I am debating using a suggestion I found in the Tomcat bug tracker. For each session store the following additional information:

SSL Session ID
HTTP User Agent
Remote IP Address

On each request I would validate that two out of the three stored values match what is captured in the session. That way one of the three could change for various reasons without impacting the user. It would be highly unlikely that a normal user would change more than one per request.

Does this seem like a reasonable additional defense for the session cookie?

From the perspective of the site developer, you should use the following:

Adopt SSL: use SSL sitewide.
Set the secure flag on all cookies.  This will ensure that they are only sent over a SSL connection.
Turn on HSTS.

This will ensure that session cookies are only accessible via SSL, and protect you from eavesdropping and man-in-the-middle attacks.
Search for SSL sitewide on this site to find many references on how to do this.
I wouldn't bother with checking the HTTP User Agent or the remote IP address.  They don't add much security and they will break legitimate use in certain scenarios.  Checking the SSL session ID (SSL session binding) would be OK from a security perspective, but may be a bit painful to configure and would not be a high priority for me: the other defenses are fine.

Other advice:
If your concern is cookie theft via XSS, the best defense is to use standard methods to avoid XSS bugs in your web application.  See OWASP for many excellent resources (you'll want to use context-dependent output escaping).
You mention "session fixation" as a tag, but that's a very different threat.  The defense against session fixation is to use a framework that is not vulnerable to session fixation.  Most modern web application development frameworks should take care of this for you without requiring any additional work.
Follow secure web application development practices.  OWASP has many excellent resources on this.
Read @Rook's advice carefully and follow it:

Checking the ip address will prevent people behind a load balancer
from accessing the site. Checking the user-agent provides no added
protection as this variable is attacker-controlled. The site needs to
be free form xss, csrf and click-jacking vulnerabilities.


Is inputting credit card numbers over a mobile phone secure? I'm in the UK. In order to top up a pay-as-you-go SIM card, I had to first ring the mobile network to associate my bank card with the SIM before asking them to credit £10 to it (future top-ups don't require a phone call). The mobile network's technician instructed me to input my debit card's full card number using my phone's keypad, followed by the CVV. This felt intuitively insecure to me at the time, but I had no way of knowing for sure.
Is this a secure or even common practice, and does it put me at risk of having my credit card details stolen?

Is this a secure or even common practice, and does it put me at risk
of having my credit card details stolen?

This is common practice, and if done properly, is secure.  This is what's referred to as a CNP (Card Not Present) transaction.
Securing card transactions over telephony is challenging and there is a PCI Security Standards document dedicated to this topic - Protecting Telephone Based Payment Card Data.
Unfortunately, you have no way of verifying how securely your mobile network provider has implemented their call center - just as you have no way of verifying most of the web sites you submit your card to, or the restaurant around the corner.  But you can trust that your card provider has chargeback mechanisms allowing you to dispute fraudulent transactions; the security carrot with credit cards is not that they'll never be defrauded, but that the cardholder will be reimbursed if fraud occurs.


Mutual authentication for humans Is there any way for two people to securely authenticate each other without access to any special software (like PGP)? For example, when speaking over the phone or by sending SMSes to each other or using some other text channel. Assume they can securely exchange any necessary secrets beforehand and also have access to software then, but at the time they need to do the authentication they have only basic phones or perhaps calculators.

Obviously the simplest thing is for each person to have a password that they say to the other, but this is not secure, because one person always has to go first. If the other is an impersonator they now have one of the passwords. So I'm probably looking for some kind of a challenge-response mechanism here - but whatever works.

So I'm probably looking for some kind of a challenge-response mechanism here

I'd guess so. Print up a few pages of text in the following format:

# Challenge Response    # Challenge Response
1 monkey    character   2 sinew     orange
3 bottle    helmet      4 glass     glove

You'll both have the same list. Whenever you authenticate it doesn't matter who goes first. Provide a challenge word and check the response. You might say, "3 - Bottle," and wait for your friend to look it up saying, "Helmet." Both of you cross the number off the list and never use it again.

They're authenticated by providing the correct word in response. Then they pick a number and do the same thing to guard against a case where your friend may have challenged an attacker, thus providing them with a number-challenge pairing and using it in replay.

The words can be random letters, the result of picking random lines from a very long wordlist, etc as long as they're randomly chosen.


Correct way to perform secure two way encryption on a web site I'm currently working a project that requires me to store sensitive information (mainly passwords and other information) on a web server via a standard python/flask website. This information is to be shared with x number of other people on the system where they can decrypt and see the information.

Ideally I'd like to perform all the encryption on the client side and keep the server storing the encrypted data in a way that means the server is never able to decrypt this data.

I was originally envisioning a system similar to that of lastpass, but with the ability to share the same data with other users to be decrypted and viewed by them I can't think of a way for this to work.

Is this possible?

[edited to add more info]

The project i'm working on is actually a password/information management app mainly targeted at companies wanting to manage their internal passwords/info for say server access or software systems with single accounts. I don't think its possible to provide users with the keys to use outside of the system. I was hoping the users password or maybe individual key of some kind would be enough to decrypt the data held in the system but being able to encrypt the data so any users key can decrypt it eludes me. I'm thinking it might not be possible.

Basically, you need to encrypt the data you want to protect using a symmetric key (e.g. AES key). This key is only known to the group of users who are permitted to access the encrypted data on the server.

The key you used to encrypt the data should not be stored on the server. The encryption and the decryption happen on the client side inside the client web-browser there are many JavaScript libraries that implement the AES algorithm.

The hardest part is how you can share the encryption key between the users. In addition, if the  same user shares part of his data with two different group of users he might need to use different encryption keys for each group. Note that you don't want to key to be known to the server

So how can we do that. There are two options for key distribution:

Use web socket to share the key between the group of users using P2P connection. The keys can be stored encrypted using the HTML5 web storage  at each user browser.
Each user has an RSA key pair where his public key is stored on the server. Then for user A to share an AES key with user B. User A download  User B public key and encrypt the AES key using uesr B public Key. Then he upload the encrypted AES key to the server. User B they download the encrypted AES key and decrypt it using his private key. Then he can use the encrypted  AES key to access user A data.

See, the technical challenge in your system is how to manage the encryption keys and how you manage the user groups.

You should take advantages of the HTML5 web storage to store the AES keys simply assign for each user a passphrase  and use this passphrase to generate a master AES key that you can use to encrypt all the keys in the web storage and other sensitive data on the client side.

Note: the main issue here if the user losses the encryption key. In this case it is possible that he might not be able to recover the encrypted data at the server.

If you post more details about your project requirements we might be able to give you a better solution and maybe a simple one.


Chrome: Watch for modified https-certificates I read a lot about security of https and possible MITM attacks lately.
For me it seems there is only possible way to make a https-MITM attack: When a MITM exchanges the shipped https-certificate and my computer trusts the signing CA.

So I'm wondering how is it possible for me as user to stay secure?
I read about Certificate Patrol for Firefox: http://patrol.psyced.org/ but unfortunately I am using Chrome and moreover the extension is pretty old (from 2011). Is there anything like this for Chrome? I like the idea of some sort of "database" of certificates so I could get a notice as soon as the certificate changes (even if it's exchanged to a new one which I trust).

Would this yield a good security layer?

Thanks!

Is there anything like this for Chrome?

No. Chrome Extensions currently have no way to access information about the TLS certificates being used, and a proposal to add this functionality was rejected back in 2015.

  Would this yield a good security layer?

Probably not.

Let's clarify the threat model here: you're concerned about a scenario where "a MITM exchanges the shipped https-certificate and my computer trusts the signing CA". This would require the attacker to obtain a valid certificate from a trusted certificate authority for a domain they do not own.

While CAs have mistakenly issued certificates to the wrong entities in the past (Comodo, WoSign, Symantec), these are pretty rare events, and CAs that consistently fail to uphold the validation requirements in the baseline requirements have their root certificates distrusted by browser vendors. (This happened to WoSign, and is currently happening to Symantec.)

Furthermore, the security benefit that these sort of alerts would provide depends entirely on your response to noticing a modified certificate. Sites change their certificates all the time (often as frequently as once every other month, such as in the case of Let's Encrypt certs managed by Certbot), so the vast, vast majority of the time this alert appears it's just going to be a false alarm. How do you plan to distinguish these false alarms from a legitimate attack? Unless you have some out-of-band way of verifying whether the new certificate you're seeing is legitimate, an alert won't do much.


Windows server 2016 Remote Desktop username leaked One of our servers got infected with ransomware last week (Matrix, .Grhan). The server allowed remote desktop connection from outside on the default port, which was a big security hole (and also, the account lockout policy was not set).

I looked at the windows event logs and found their bruteforce tries, it got so many login failed entries, that I only have logs for the last few days before the attack. They managed to find the password of a user who set it to something really easy to bruteforce. One of the things I noticed that they seem to knew our usernames and I wonder how. They tried a bunch of random names too, but most of the tries were for existing usernames (I exported the names to a text file and made a report from it, counting each try for each name. Almost 90% of the tries went to existing usernames).

How is that possible? I read the answer here, but our server is a Windows Server 2016. I ran two scripts made for taking remote desktop screenshots and could not connect. One of them mentioned that NLA is enabled on the server.

You are assuming they extracted the names from the server. If they did it would not make sense to try any other names as well.

It is more likely the list of names was obtained via a different method, for example a leaked list of email addresses.


Who can certify RNG according NIST SP800-22? I have written my own random number generator as a C library and I tested it on NIST Statistical Test Suite.

Now I would like to get a certification to have a formal proof that my C library generates random numbers randomly enough according SP800-22.

On a NIST web pages I'm not able to find some list of independent laboratory that could take my library, test it, and provide me certification.

Where can I find a list of companies/independent laboratories that can certify my RNG library according NIST SP800-22?

This certification is typically done through FIPS certification.

The list of labs certified by NIST to perform FIPS certifications is here


Is there any documentation or reviews about LINE messenger security? I tried to find any documentation about the security of LINE messenger, but I couldn't.

Is there any documentation or reviews about the communication protocol it uses, and whether or not it uses end-to-end or point-to-point or no encryption?

Most pages are in Japanese, but they do have a nice blog with the occasional english page. Altho this one isn't about security specific, it does talk about how they send messages http://tech.naver.jp


If I misuse OAuth 2.0 to do authentication, am I at risk? I understand that OAuth is not an authentication protocol, but an authorization one (even if the first paragraph on Google's OAuth 2.0 page disagrees), as well as that:

  [...] authorization can be abused into some pseudo-authentication, on the basis that if entity A obtains from B an access key through OAuth, and shows it to server S, then server S may infer that B authenticated A before granting the access key.

and that I should use OpenID when I need to authenticate a user.

However, does it mean that if I actually use OAuth (not OpenID Connect, but OAuth 2.0) with Google, does it mean that my web application is not secure? Can it be compromised to gain access to an account or do something wrong? Can a user forge something to pass for another user?

To make the question a bit less abstract, let's assume that:

The libraries I use, such as Flask-OAuth for Python and similar libraries for other languages, are secure.
I trust Google,
Google account of a user is not compromised (if user's Google account is compromised, an attacker is indeed expected to have access to the user's account on my web application),
The FAI/hosting service/other man in the middle should not be trusted,
Anyone who has a Google account can login/register/whatever,
I don't need the user's e-mail address, first/last name or other personal information to be true; all I need is to keep data of one user protected from other users.

The main issue is making sure that you protect against the confused deputy problem.

Imagine you are using OAuth to authenticate users within your application.

However, an evil developer has their own application which also uses OAuth. Say their application is a Solitaire game, which uses Google's OAuth API. A user authenticates for Solitaire using their Google account.

However, the evil developer takes the authorisation they got from Google from the user and plays it to your app instead. Because you are using OAuth for authentication, you are taking the authorisation token as an authoritative statement that the user is in fact your user that you wanted to authenticate, but it is not - it is the attacker using the authorisation token to authenticate as that user. Therefore, the attacker has abused your authorisation in order to trick your application that the user is in fact authenticating with you.

This blog explains it well. Note that they use the phrase "cross site scripting" when I think they mean "cross site request forgery".

You can mitigate this by properly validating the audience parameter. You should also set a state and validate this on the callback because this can prevent a CSRF attack from performing a "login CSRF" attack on a user of your application (e.g. if your application synced data to Google, an attacker making another user appear to be logged in as them could steal the synced data to their Google account).

Also see this answer.


How to capture HTTP Traffic if the application uses Automatic Configuration Script? I am testing an application that requires "Automatic configuration script" to be configured in web browser.

How can i intercept HTTP traffic in such case. I am aware of temper data add-on but is there a way to configure HTTP proxy (such as burp/paros) in such case?

Got the solution. Using Upstream proxy in burp suite this can be accomplished. Burp will forward the traffic to the proxy URL and will receive the response.


Cracking DES(Unix)/MD5 ARP This is a basic example of an Unix Pass Encryption.

I have a little Hash of MD5 ARP:

user50:$apr1$w7YNTrjQ$0/71H7ze5o9/jCnKLt0mj0
user60:$apr1$AIw2h09/$Ti0TRlU9mDpCGm5zg.ZDP.

I need to find the pass of two users: user50 & user60.

I was wondering, what is the best way to crack this hash? Maybe with John the Ripper? Is there a better alternative?

I would suggest John the Ripper. Get a large dictionary file and run it through John. You could even split it among multiple machines (possibly in the cloud) as the problem is very parallelizable.

John can even do variations on dictionary words like substituting 0 for o.

For more info, see this article.

If you have access to a GPU, oclHashcat looks interesting.


TLS 1.2 Handshake: Does the server have to take all extensions sent by the Client? I am unsure about how extensions are handled in TLS v1.2.

During the handshake, the client is able to add some extensions during ClientHello.  As far I understood, the server can pick arbitrary subsets from this list in ServerHello similar to picking the cipher suite, which the client provided during ClientHello.  Is this correct?

If not, is it that the server can either take all those extensions into account, or must abort the handshake?  I am not sure which is true.

I was looking for an adequate answer here in RFC5246, but didn't really find the one statement I am looking for.

Yes, each extension defines what it means.

A server that has never heard about this extension (e.g. the server is old and the extension is new) just disregards it, and the client must be ready to deal with that (at worst, by breaking the connection after ServerHello, but usually by falling back to the behavior before the extension was defined).

The extension spec should say what the server should do if it sees it and doesn't want to support it and what it should do if it does want to support it.

For example, a client might decide to drop the connection if the server didn't use SNI to choose the cert (and indicated that by server_name extension in ServerHello), or a client might decide that OCSP stapling is required, or certificate transparency SCTs are required, or a client might decide to drop a connection if a CBC cipher suite was chosen and no agreement to do encrypt_then_mac was indicated by encrypt_then_mac in ServerHello. Or a server might drop connections from clients that don't send server_name.


Why are hash functions one way? If I know the algorithm, why can't I calculate the input from it? Why can't a password hash be reverse engineered?

I've looked into this ages ago and have read lots on it, but I can't find the explanation of why it can't be done. An example will make it easier to understand my question and to keep things simple we will base it on a hashing algorithm that doesn't use a salt (LanMan).

Say my password is "Password". LanMan will hash this and store it in the database. Cracking programs can brute force these by hashing password guesses that you provide. It then compares the generated hash to the hash in the database. If there is a match, it works out the password.

Why, if the password cracker knows the algorithm to turn a plain text password into a hash, can't it just reverse the process to calculate the password from the hash?

  This question was IT Security Question of the Week.
  Read the Feb 24, 2012 blog entry for more details or submit your own Question of the Week.

Let me invent a simple "password hashing algorithm" to show you how it works.  Unlike the other examples in this thread, this one is actually viable, if you can live with a few bizarre password restrictions.  Your password is two large prime numbers, x and y.  For example:

x = 48112959837082048697
y = 54673257461630679457

You can easily write a computer program to calculate xy in O(N^2) time, where N is the number of digits in x and y.  (Basically that means that it takes four times as long if the numbers are twice as long.  There are faster algorithms, but that's irrelevant.)  Store xy in the password database.

x*y = 2630492240413883318777134293253671517529

A child in fifth grade, given enough scratch paper, could figure out that answer.  But how do you reverse it?  There are many algorithms people have devised for factoring large numbers, but even the best algorithms are slow compared to how quickly you can multiply x by y.  And none of those algorithms could be performed by a fifth grader, unless the numbers were very small (e.g., x=3, y=5).

That is the key property: the computation is much simpler going forwards than backwards.  For many problems, you must invent a completely new algorithm to reverse a computation.

This has nothing to do with injective or bijective functions.  When you are cracking a password, it often doesn't matter if you get the same password or if you get a different password with the same hash.  The hash function is designed so it is hard to reverse it and get any answer at all, even a different password with the same hash.  In crypto-speak: a hash function vulnerable to a preimage attack is utterly worthless.  (The password hashing algorithm above is injective if you have a rule that x < y.)

What do cryptography experts do? Sometimes, they try to figure out new algorithms to reverse a hash function (pre-image).  They do exactly what you say: analyze the algorithm and try to reverse it.  Some algorithms have been reversed before, others have not.

Exercise for the reader: Suppose the password database contains the following entry:

3521851118865011044136429217528930691441965435121409905222808922963363310303627

What is the password?  (This one is actually not too difficult for a computer.)

Footnote: Due to the small number of passwords that people choose in practice, a good password hash is not merely difficult to compute backwards but also time-consuming to compute forwards, to slow down dictionary attacks.  As another layer of protection, randomized salt prevents the use of precomputed attack tables (such as "rainbow tables").

Footnote 2: How do we know that it is hard to reverse a hash function?  Unfortunately, we don't.  We just don't know any easy ways to reverse hash functions.  Making a hash function that is provably difficult to reverse is the holy grail of hash function design, and it has not been achieved yet (perhaps it will never happen).


Should I check Host header or ServerName for CSRF defense when serving behind proxies? In a CSRF defense based on checking forbidden headers, should I check Origin/Referer header against the ServerName configuration directive, or is it sufficient to simply check against the HTTP Host header?
I'm asking because I'm trying to make my application ready for proxies. Load balancers on public networks are one of the many possible use cases, but local SSL/TLS wrapper is more urgent as we need to test WebCrypto API usages in secure contexts.

According to OWASP Cheatsheets, both are fine. I would object checking X-Forwarded-Host, as it's not a forbidden header.
You can do the following check, and it will be compatible in most cases: ( $Origin or $Referer ) == ( $Host or %ServerName% )
As for the load balancer part, if you're considering deploying a commercial CDN for your application, the following configuration may be usable (it's based on Apache HTTPD, other servers would have different config directives):
UseCanonicalName on
<VirtualHost *:*>
  ServerName app01.example.com
  ServerAlias app01.source.example.com
  ...
</VirtualHost *:*>
...

And configure the DNS servers to resolve app01.example.com to the CDN, and point the CDN to app01.source.example.com. This way, when an HTTP request arrives at your server, Origin/Referer will match ServerName in your server-side CSRF defense codes.


Gaining root access on an Android phone exploited with MetaSploit I have been using MetaSploit for a while (3 years), and I have just started exploiting Android.

My Android has root access, and SuperSu is configured to 'grant' all SU requests.

I have the payload installed on my phone, but, whenever I try to use POST modules in MetaSploit, I get the message

This module requires root permissions

How would I get root permissions?

It sounds like this will fail to show root

meterpreter> check_root

With one of the following outcomes:

  [+] Device is rooted

  [-] Device is not rooted

If the second, probably best to try

meterpreter> shell

  Process 1 created.

  Channel 1 created.

id

  uid=10005(u0_a5) gid=10005(u0_a5) groups=1015(sdcard_rw),1028((sdcard_r),3003(inet)

su
id

  uid=0(root) gid=0(root)

See more here -- http://blog.itselectlab.com/?p=6931


How to deny execution of any file on a specific directory? I built a form that lets the user to upload files to a specific directory (apache2, php). I already limited file type and did some other security things. But I would anyway also like to deny the execution of those files to all. They're meant to be only downloaded. I've got the following code for htaccess, but it's a fake one, not sure of the syntax, nor if it's the right way of doing it:

<Location "/example/mydir/">
    <Files .>
        ForceType application/octet-stream
        Header set Content-Disposition attachment
    </Files>
</Location>

Could you please help me correct that code or change it to best practices?

If you want to make sure that the files are not executed, then the best way is to not let users access the files directly.

"But how do you download them if you cant access them?" you might ask. Answer is that you provide a public facing download script that fetches the local file and presents it as a forced download to the user.

You can look at this to see how that can be accomplished.


Skill testing question in registration page I've seen some registration pages that have a "skill testing question" in addition to having a captcha. These skill testing questions are usually easy trivia, such as "what is 2 + 2" or "who invented the light bulb?". Registration will not go through unless the correct answer is given. What is the reason behind having such questions? If a bot already got past the captcha, there never seems to be a large pool of questions so the answers could be hard coded in. If a human in a 3rd world country is getting past the captchas (which to my understanding is why they don't work well) they could also solve a skill testing question (provide they have access to a search engine).

Bots are usually made generic.
There is no bot to register specifically at Celeritas.domain and post spam.
There is a bot to register at any generic Wordpress/xForum/yCMS site and post spam.

It is very hard to generically write a bot that can answer "What is one plus -2", "What color is a Firetruck?", "What is the name of this Blog?" and whatever else such registration questions can be.
Posting spam on a single website is (currently) not valuable enough for this Spammers to pay humans to solve this things.

If there is a new Captcha system used at many domains, it is worth the effort to implement that. For a single site, the effort just isn't worth it, it seems, even if the effort is very low.


Best practice for data security on a web application I read a couple articles on privacy/security but still cannot get a clear picture of the best practice to ensure that an attacker will not be able to access users' private information.

For storing passwords or other data that will be checked only to verify authenticity, I understand that hashing algorithms like SHA-256 are perfect candidates as the password itself doesn't need to be stored (or even known) on the server-side.

However in my case, in addition to the password, I allow users to store other secrets that the server needs to be able to decrypt for background work that will read these secrets to provide historical stats, without the user to be logged in. These "secrets" are usually api keys to external services, that could be dangerous if in the wrong hands.

A possible solution would have been to use the user session or cookies to store the secrets, but in addition to being subject to cookies or session hijacks, it requires the user to be logged in to work, and in my case I need the server to be able to decrypt and use the secrets for background tasks without the user being logged in.

So another solution would be to encrypt the secrets in the database using for example AES-256 and keeping the encryption passphrase outside the database. If the attacker gets access to the database, he cannot decrypt the user secrets. If the attacker gets access to the server's filesystem, he gets access to the passphrase, but not the DB... oh, wait a minute, why not the DB? If the attacker gets access to the server's filesystem, including config, he also gets access to the database as the connection strings are also in the config on the filesystem. So if the attacker gets access to the filesystem, he gets access to the passphrase AND the db...

I can't think of any solution to truly separate the passphrase from the db. Am I missing something? Is there any real solution to protect user secrets so that at least 2 different systems (DB / files) have to be hacked to get access the secrets, knowing that the server needs to be able to encrypt/decrypt the secrets without users help?

My project will be running in the cloud with nodejs as web server and mongodb as database and before opening it to the public I'd like to ensure it will be almost impossible for an attacker to retrieve the users secrets, which doesn't seem to be the case.

Edit: Instead of storing the passphrase in the config, I could actually pass it in the command when starting the web server (nodejs in my case). So instead of reading the passphrase from the flat config file, it reads it from the command-line.
Doing that would ensure the passphrase is never written in a file (assuming I can disable the bash history) and is only in memory, which is harder to hack isn't it?
The only drawback is that I need to manually start the server if it goes down, as starting automatically will start without knowing the passphrase (so I need to start it myself). But would it work? Is that a known and used practice?

You're right that there isn't a great solution.

Yes, entering via CLI and storing in RAM is sometimes used, but dumping ram isn't too hard.  There are hardware security modules that specialize in this scenario (research this term if this problem is important enough).

Generally speaking, it's best to store it in a folder which has its permissions very restricted, then focus on hardening the server so the attacker has to do two difficult things (exploit a service, then escalate privileges).  Don't store it in the database or in a directory accessible to the web user.

Encrypting it using AES would be good.  If the attacker can control the plaintext or observe the ciphertext in any scenarios you'll want to take much greater precautions to ensure it's implemented correctly.


Why does this XSS challenge require %0A to work? I came across this hack.me XSS challenge.

Solution to this challenge is:

javascript://%0Aalert(1)

I'm confused with %0A. Why does it not work with this payload?

javascript://alert(1)

It's required to terminate a Javascript comment.

The challenge enforces a link format along the lines of [a-z]*://.*. Here, the idea is to inject JS via the javascript: pseudo protocol. So, in order to adhere to the link format, you have to start your sequence with javascript://.

But since everything behind the colon is interpreted as JS, you run into a problem: // introduces a single-line comment in JS, so everything that comes after it will be commented out until a newline character appears. This will do nothing:

//alert(1)

%0a is the URL-encoded version of an ASCII newline, so your payload effectively becomes this:

//
alert(1)


ASCII to HEX to obscure filenames: Is this common? I've been learning about ethical hacking, and utilizing the wonderful resources that helpful organization like OWASP and OpenDNS have provided for learning and testing.  However, I sometimes come up against challenges that I'm not sure are 'real world' examples.  I recently found a challenge that required me to notice that the filename on a web application was converted from ASCII to HEX to obscure the file name.

My question is simply this:
Is ASCII to HEX obscurity something relatively common real world? If I'm someday helping a company find vulnerabilities, would this be something I should keep high/mid/low my list of vulnerabilities to look for?

I've worked in I.T. for over 8 years, and I'm not sure I recall seeing HEXed versions of filenames used for obscurity before,so I'm just trying to get some context.

Nope - it's a contrived situation for CTFs. Helps to train you in dealing with different encodings.

Security by obscurity has a niche place, but only as a layer on top of a more robust security framework. Typically you would need a very specific threat scenario for obscurity to make sense as a risk mitigation technique.


Do vBulletin and similar discussion forum CMS store previous email address and password hash in database? I am in the process of De-Googling myself and setting complex passwords.

I changed my registered Gmail to an alternative mail provider
I changed my password to a complex one

I use mostly vBulletin and similar forums.
It's very well known that Facebook, Apple, Microsoft, Google and Amazon never delete any old records.
But does this also apply to off-the-shelf forum CMS systems? Can the admin see my previous email address and password hash?
Please describe how this is handled for the most popular discussion forum CMS (vBulletin, Discourse, phpBB  and Simple Machines Forum). It's a privacy issue, so I don't want the admin to store my previous email and password hash.
It's very clear that the old records are in backup (mysqldump), so I’m asking more about the live DB.

Many off the shelf bulletin board and similar forum software are simplistic enough to not store history of changes. However some are more complex and do.

One way to positively identify ones that do (although the reverse is not true, this will not prove a negative) is to change your password to something, then try changing it back to the original. A good password change function will not allow you to re-use the most recently used n password hashes as this is a common user security compromise. If the system is able to block that behavior, then it is keeping password hashes.

As a rule of thumb, you can bank on their being some history out there, not necessarily from the website software itself, but from server backups. Anybody who snapshots their servers or runs regular dumps on their databases for backup purposes is going to have a some records with your old info floating around somewhere. The likelihood of these ever turning up anywhere is low, the as an end user your chances to find and eliminate them are even lower.


Can a static (HTML only) site be vulnerable to XXE? First of all sorry if I am asking a trivial question.

As far as I know, XML is used for representing document structures. Can entirely static sites accepting no user inputs at all be vulnerable to XML, DTD and entity attacks?

If it happens, In what context is it possible ?

So XXE is usually seen in areas of a site which accept user input.  If by static site, you mean a site that purely responds to HTTP GET requests for documents hosted on a server, then there's not really anywhere for XXE to occur.

The only scenario I could think of would be if the site processed a section of the URL or HTTP headers and included that as an entity in a request to an XML web service, but then at that point your site isn't really static!


Storing user's social media passwords I'm trying to understand how a service Snaplytics trusted by some high brand companies is able to collect their clients password for snapchat and store them in their db while being able to log in to their Snapchat account periodically. My understanding for storing passwords is to use a safe method like bcrypt. To never store plain text passwords. But if Snaplytics is periodically logging into accounts, they need the plaintext password to log into Snapchat. But I'm pretty sure bcrypt is a one-way hash function so how does snaplytics manage to "secure" clients password along with logging into their account.

Below is an image of requesting passwords where they state that "your password will be encrypted and stored securely"

Snaplytics says that they encrypt the password, not hash it.  When data is encrypted, it can be decrypted back to the original plaintext with the use of a key, which Snaplytics hopefully keeps secure internally.  In this way, the passwords are not stored in plaintext and are difficult to retrieve if Snaplytics' database is compromised, but when Snaplytics needs to log in to a user's account they can retrieve the plaintext password just long enough to authenticate with Snapchat.  I took a cursory look over their site and don't see any information about what specific encryption they are using.

You are correct that when you are running a service which uses password authentication, you should hash passwords before storing them in the database because you do not need the actual plaintext password.  However, Snaplytics has to transmit the password to Snapchat in plain text so Snapchat can (hopefully) hash it on their end and use it for authentication, so Snaplytics does not have the option of storing it via a one-way hash.


What is the risk of unlimited email event triggering? Let's say I can trigger a mail event in a few scenario's without any a limit on that trigger. For example at:

Registration
Password reset
Newsletter subscription

The "registration" and "newsletter subscription" can be done on all email addresses and the "password reset" trigger likely only on existing accounts.

Is there any other risk than just misusing this mail trigger for sending annoying emails to email addresses, that didn't ask for it?

I was thinking in the direction of resource exhaustion because the mail-trigger might take more resources, so calling it more often on a larger scale takes resources on both sides, client and server-side.

Using the feature for "sending annoying emails to people who didn't ask for it" is indeed a real risk, as you point out. You could e.g. use this on a competitor in the hope that the random recievers will start marking the mail as spam, so that spam filters will catch on and start blocking your competitors emails. But let's leave that to the side and focus on the resource aspect.

If you want to exhaust resources, you should focus on the functionality that does most of the heavy lifting. Sending an email is not hard work. Other things, like login (computing hashes), advanced searches or generating large amount of data that can not be cashed are. An attacker is more likely to start there, and move down to less resource intensive tasks only when those are blocked. Sending an email should be very, very low down on the list.

The only situation I could think of is if your hosting provider has some rules against how many emails a month you can send (shared hosting often has lots of limitations of all sorts).

(This answer has focused on the server side. I am not sure what you mean by "client side" in this case.)


Impact of SQL injection on SELECT statement During a routine penetration test I encountered a possibility for SQL injection. The following criteria apply:

Microsoft SQL Server (2016);
Query has to start with SELECT;
The semicolon ; is not allowed to break a statement and to start a new one;
Everything else is allowed.

I am wondering what the highest possible impact would be for an SQL injection vulnerability like this one. Obviously information disclosure is possible, but I would like to know if it is also possible to actually 'break out' of the SELECT statement and to DROP a table for example. What would you suggest for this scenario?

I'm not 100% certain on this first detail so I'll defer to anyone who disagrees, but I'm pretty sure that your stipulations mean that it is not possible to break out and execute a DROP, INSERT, UPDATE, or anything other than a simple select.

As a result the worst case scenario is limited to information disclosure, but keep in mind that the worst case scenario is most likely a complete leak of your entire database.  With MySQL at least (I'm not familiar with the details of Microsoft SQL Server) the table structure is also stored as tables that can be accessible via a SELECT operation and so SQLi vulnerabilities on a SELECT usually start by first figuring out all column and table names (presuming that you can perform arbitrary SELECT injections - which is what it sounds like).  Once you have that it is very easy to join and dump all tables and columns, resulting in a complete copy of your entire database (as well as any other databases that the SQL user has access to).

A quick google leads me to believe that database structure is accessible via SQL select commands in Microsoft SQL just like it is in MySQL - ergo a full database copy is possible in the event of a wide open select vulnerability.


How to completely remove all traces of a file in Windows 7? I'm curious to know how to completely erase all possible traces of files in Windows 7.

For example, let's say I have a subfolder containing five different files at work deemed sensitive (A document, a video file, a RAR, an image, and text file).

What are the steps I have to take if I want to completely erase all traces of these files without reformatting or doing something similar?

I can think of only a few things:

Erase Temp files stored by WinRAR
Delete the thumbnail icon database stored in AppData (.DS file)
Disable Data storage by the Windows 'hibernate' feature
RAM

Am I correct in assuming that simply "shredding" a folder won't completely erase all traces of the files in said subfolder?

Is it safe to assume that using software such as CCleaner would sufficiently remove all traces of said subfolder (if using the 'secure delete' option)?

How can I reach a state of confidence where I can remove all traces of these files, and bring my work laptop home knowing that the files and all traces of those files are completely wiped out? (Or can I ever be completely confident?)

The Honest Truth Answer:

Unless you physically destroy the drive by putting it through a metal shredder, there is no way to completely prevent that information from having a chance to be recovered by a skillful individual.  If government level actors factor into your threat model, then you need to physically destroy the drive.

The Good Enough Answer:

If the NSA, FBI, Chinese Intelligence, etc. do not factor into your threat model, then you can get by with applications such as CCleaner.  For all but the most extremely sophisticated threat actors, a 25+ pass rewrite will suffice on a HDD.

SSD are a different matter all together due to wear leveling (as Rory already stated) and about 30%+ of the SSD industry are not following the established standard practice for how to handle rewriting those "Bad" memory blocks.  Which brings me back to the honest truth answer, shred the drive.


Getting mixed results testing for TLS 1.0 support I am scanning IPs (owned by my company) to determine which servers still support TLS 1.0, with the goal being to identify them and disable TLS 1.0 support.

I'm wondering if someone could weigh in on my methods of testing as I'm getting mixed results.

When using http://www.serversniff.net/tools/httpstlscheck.php - it returns that TLS 1.0 is NOT enabled:

Checking protocols sslv2, sslv3, tlsv1, tlsv1.1, tlsv1.2
sslv2 server does not support sslv2
sslv3 server does not support sslv3
tlsv1 server does not support tlsv1
tlsv1.1 server does not support tlsv1.1
tlsv1.2 server does support tlsv1.2

When using the command openssl s_client -connect x.x.x.x:443 -tls1 it connects, and shows what appears to be a valid TLS 1.0 connection:

SSL handshake has read 3418 bytes and written 315 bytes
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : ECDHE-RSA-AES256-SHA
Session-ID: BE04A17FD209D42326FC2AC4DFB9456BBD3BFA89AACF4C8A614C3B
Session-ID-ctx:
Master-Key 14177405E2C3D11DB8E63dBA5AC179D26B1E8EA838EC2E309D3AD2CBE0C57DBB4B179854EBB6CCE86A9D50
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1532456238
Timeout : 7200 (sec)

Verify return code: 0 (ok)

Finally, when testing in IE, I can uncheck "Use TLS 1.1" and "Use TLS 1.2" and only have "Use TLS 1.0" checked. I can make a connection to the site (after restarting IE) in this way.

I am safe to assume that my openssl test is correct, and that the serversniff.net results are incorrect?

Assuming the serversniff.com showing incorrect results for this. OpenSSL, when compared to ssllabs, checked out ok.


Password security with short passwords I know that a long password is a good password. However, some sites require short passwords e.g. exactly 8 characters long.

Under those limitations, what is a good method of creating and memorizing a (relatively) secure password?

With eight characters you're extremely limited.

My advice - forget the memorisation part.

Generate an eight character string using a cryptographically secure pseudo random number generator, using letters (both cases), numbers and symbols. This will give your password 52 bits of entropy, which is the maximum you can achieve using this scheme. The alternative would be to start using unicode characters if these are supported, as a much greater key-space can be achieved. However, entry of these passwords may be difficult depending on the devices used. This would enable you to achieve the 80 bits necessary for a secure password.

Use a password manager to remember the password for you - this can be a memorable password, however make sure that this has enough entropy to make it secure. This is the best way to achieve memorability and security of your passwords, because you only have to remember one password.

For example, the LastPass generator is here. However, make sure your browser supports the Web Cryptography API, otherwise unfortunately this one falls back on current time as seed and uses a standard PRNG. You should be OK with any modern, popular browser.


How is the security of SSH affected in the presence of a passively monitoring MITM? In an ideal world, where all links are fully trustworthy from a data integrity point of view, with proper settings, modern SSH can be more or less assumed to be fully secure against eavesdropping on the content of the communications, but may leak metadata (e.g. the fact that you are connecting to a specific host, and some about the usage pattern and amounts of data transferred).

In a somewhat more realistic world, however much we might not want that to be the case, links should be expected to be monitored. We know that encrypted traffic may be specifically retained by powerful adversaries. However, there is still a big difference between passively monitoring traffic on the one hand, and actively tampering with it in-flight on the other.

Assuming that:

the initial SSH host key is generated by unknown, possibly flawed, means;
the administrator cannot directly verify the correctness of the SSH host key presented by the server on the first connection, beyond being able to tell whether the login attempt succeeds or fails, but can verify the host key fingerprint via commands within that session once established;
the administrator quickly replaces the SSH host key with one generated in a trustworthy fashion and reestablishes a connection once the new host key has been loaded;
the administrator diligently confirms SSH host key fingerprints between the client and the server;
the administrator does not have access to a distinct channel to the server for key maintenance, so key replacements have to be performed through the SSH session established with the host key that happens to be on the server at the time;
the attacker does not have access to the SSH private host key on the server, but can monitor, store and later process all communications to and from the server.

In such a scenario,

what security guarantees can SSH-2 give against eavesdropping on the content of the communications (violation of confidentiality)?
are these security guarantees any different in the initial connection (before the host key is replaced) and later connections?

I don't know internals of ssh protocol, so my answer is based on general knowledge of cryptography and isn't guaranteed to be right. Well, nothing is.

If the initial ssh key was generated in some "bad" way, then it might be possible or might be impossible for attacker to decrypt your initial connection to the server (it depends on how the session key is generated in ssh - thing that I don't know).

If you regenerate the ssh key on server in a right way and reconnect to the server then, I believe, the eavesdropper wouldn't be able to decrypt anything inside you ssh connection. Since the new key is "good" and the eavesdropper doesn't know it's private part (it wasn't transferred over the network, only it's fingerprint was).

That should be right if the attacker is eavesdropping only. If he can actively tamper with your traffic you have no security guarantees in any of the two cases:

the initial key was generated "badly"
admin doesn't know the key fingerprint from trustful source before connecting for the first time


Are revoked certificates removed from CRLs after expiration? Why is this secure? If a certificate is revoked before its expiry time and added to a CRL, is it removed from the CRL after the certificate validity period expires? RFC 5280 seems to imply this:

  A complete CRL lists all unexpired certificates, within its scope,
  that have been revoked for one of the revocation reasons covered by
  the CRL scope.  A full and complete CRL lists all unexpired
  certificates issued by a CA that have been revoked for any reason.
  (Note that since CAs and CRL issuers are identified by name, the scope
  of a CRL is not affected by the key used to sign the CRL or the key(s)
  used to sign certificates.)

(Page 54)

  The removeFromCRL (8) reasonCode value may only appear in delta CRLs
  and indicates that a certificate is to be removed from a CRL because
  either the certificate expired or was removed from hold.

(page 69)

However, if this is the case, how would this situation be resolved securely?

A certificate is issued
The cert is compromised and revoked, added to the CRL
The Attacker signs something with the revoked certificate
The certificate expires
The cert is removed from the CRL, clients update their local copies of the CRL
A client receives the data and signature from the attacker and verifies it.

From my understanding, a signature that was created during the validity period (i.e. before expiration) of the certificate will stay valid even after the cert expires, as the cert was valid at that time. So, how would the client determine that the cert was revoked when the signature was created, if the information is no longer part of the CRL?

This question was marked as a potential duplicate of this one. The replies to that question seem to indicate that expired certs are not removed from CRLs. If someone can clear up the discrepancy, I would be grateful.

This is default behavior for most CRLs. And yes it leads to the issue you have mentioned. In practice many systems have workarounds. Its a delicate situation because CRL bloat is a big issue in of its own.

For SSL this isn't an issue - the expired certificate would be rejected because you expect the server to sign on request.

ADCS (Active Directory Certificate Services) has a flag to indicate whether a certificate revocation should remain in the list permanently.

*As per my comment default behaviour differs slightly from your posted explanation. As pointed out by @SmokeDispenser certificates remain until one update from expiry.


Is it possible to hack a phone just inputting dialer codes? I'm currently in Germany, and today a woman asked if she could borrow my phone on the street, as she needed to make an urgent call. The thing is that I lended her my phone and, while I was making sure my wallet was safe (she gave me a very weird vibe), I noted she was inputting some dialer code (something like #number#othernumber) on my (Android; Samsung) phone and doing something strange with hers. When I noticed it, she hid her phone, she moved a bit doing as if she was calling, and then I asked her to give my phone back. She did and told me that "the person she was calling must be asleep", gave my phone back, and then quickly went away.

I checked the call she did and it lasted 5 seconds, and there is only a number and no trace of the code she inputted on the dialer (I'm pretty sure I saw a couple of # symbols on the dialer). A couple of seconds after, and just for "security" I turned off my phone, but later I had to turn it on again to check some emails.

Some questions:

Is it possible to list all the codes dialed in my phone in order to check what she did?
What could she have extracted from my phone? Could she have installed something? I had Bluetooth turned off, and only phone calls and internet could be used.

Any help would be greatly appreaciated, as there are bank apps on my phone that I think could have sensible information.

She could of done 2 things that would make you pay something extra:

Hailed a number that overtaxes and since the first minute is most of the time taxed by default no matter the duration up to 60 seconds she actually did make some amount of currency with the few seconds when it was active
Sent a text message to a special service, again, overtaxing you

By your description, it was a call, not a text. Using "#" parameters she left no trace of the destination. Only your mobile operator could help you identify the destination unless you had a key-logger active.


What is the benefit with passwords that are always 50% numbers and 50% letters? In Teamviewer, I am using "secure (8 characters)" passwords that are changed daily. I noticed that the password is always 4 numbers and 4 lower case letters, with random positions.

I might be naive, but isn't that less secure, because it reduces the amount of possible alphanumeric combinations? Or is it more secure because there'll never be an 8 digit password that is letter only or number only? My intuition says no, but then why would Teamviewer do this...

Warning: A previous version of this answer contained a big math error leading to incorrect conclusions. It has now been fixed.

Let's calculate some entropy!

A random password consisting of 8 lower case letters or digits:

log2((26 + 10)^8) = 41.4 bits

A random password, where exactly 4 characters are lower case letters and exactly 4 are digits:

log2(26^4 * 10^4 * (8 choose 4)) = 38.2 bits

A random password, containing exactly 8 lower case letters:

log2(26^8) = 37.6 bits

So, what conclusions can we draw from this?

As you can see, we lose some entropy - almost 3 bits. This means the password would be about 7 times faster to crack.
To do this to avoid passwords with only lowercase is a bit misguided, since now all passwords are almost as bad as lowercase only passwords.
The best guess is probably that this is a UX decision. The mix makes them easier to remember and read aloud. The loss of entropy (less than the equivalent of removing one character) could be deemed "worth it".


How to completely destroyed all data from an iPhone before reselling it? I would wish to know more about how to erase 100% data of a used iPhone.

Basically, technician from Apple Store only said “Erase & Clear” within the iPhone setting could do all the work perfectly and all data of an iPhone are encrypted, so there is no way anyone could steal any traces of the data.

I am not sure about that answer as I believe the hard drive in a iPhone works the same as computers which means old data could only be completely erased unless they have been overwritten by new data. My speculation was confirmed by a iPhone data eraser tool called “iShredder”, as it claimed it would help to erase everything up to security agency standard.

So my question is if “iShredder” is a legitimate tool for going forward about erasing iPhone’s data in the most professional way? What do you think?

If the iPhone had used some APPs in connection with entertainment like music and movies, sometimes they offer you an off-line viewing by caching the content, does that mean it is not different from downloading those data on your hard drive of the iPhone, which means you would have to overwrite them completely in order to erase them, and “Clearing cache” option in those Apps only marked them as deleted but not exactly erasing them?

Also, when you are trying to delete photos when the iCloud is full, it says they would be deleted immediately and you would not be able to recover them from “Recently Deleted”, does that those photos were also completely gone or again were just marked as “Free Space” until new data overwrites them in the hard drive?

Sorry for a series of questions and looking forward to your advices on this! Many thanks!

Like many modern smartphones, the iPhone uses flash storage. A flash memory cell has a limited number of rewrite cycles. Two things make data shredding on flash storage difficult:

Wear balancing: the storage controller will automatically remap physical storage blocks to ensure that all storage cells are used equally. This also means that overwriting a file in place will actually rewrite the file in a different physical location before the storage controller remaps it to same virtual location.
Overcapacity: a flash memory device always has more physical storage than its advertised capacity. This extra space is used by the storage controller to replace bad blocks that have died so the end user won't see decreased capacity over the expected lifetime of the drive.

These things combined mean that overwriting the drive until it runs out of space is not guaranteed to wipe out all traces of your data from the drive. So it has become standard practice to use full disk encryption on flash storage, so that deleting flash storage can be done by simply removing the encryption key.

Assuming the encryption is solid, this should be a much more reliable way to delete all data in a flash storage device. Some users still overwrite as much data as possible by creating files until the disk is full, in case there's a vulnerability in the encryption or their encryption key was compromised. While this isn't necessary, you should do so if it eases your worry.


WIN 10 hardening: Importance of "Allow system to be shut down without having to log on" policy I am enforcing a hardening policy on my organization's work stations.
One of the policies I removed, under Shutdown, is called "Allow system to be shut own without having to log on".

Users started to complain and asked us to re-enable this policy, and I tend to agree. Can you think of a good reason why to disable ?

That policy may source from the CIS Benchmarks, but is intended for servers, not for user workstations.  To quote §2.3.13.1 (and note the Profile Applicability and Impact sections):

  2.3.13.1 (L1) Ensure 'Shutdown: Allow system to be shut down without having to log on' is set to 'Disabled' (Scored)

  Profile Applicability:

  Level 1 - Domain Controller
  Level 1 - Member Server

  Description:

  This policy setting determines whether a computer can be shut down
  when a user is not logged on. If this policy setting is enabled, the
  shutdown command is available on the Windows logon screen. It is
  recommended to disable this policy setting to restrict the ability to
  shut down the computer to users with credentials on the system. The
  recommended state for this setting is: Disabled.

  Rationale:

  Users who can access the console locally could shut down the computer.

  Attackers could also walk to the local console and restart the server,
  which would cause a temporary DoS condition. Attackers could also shut
  down the server and leave all of its applications and services
  unavailable.

  ...

  Impact:

  Operators will have to log on to servers to shut them down or restart them.

The idea being that a user might not have privileges to log into a server, but with physical access, they would be able to shut it down.  Consider the HVAC guy working in your server room, etc. etc.

It is reasonable for you to allow your users to shut down workstations.


read raw dump with WinDBG Is it possible to convert a full raw dump memory and open it in WinDBG ? In order to inspect if they are no malwares, filter process who call particular API, dump each process in memory etc...

Yes, it is possible to analyze a kernel mode dump in WinDBG:  https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/analyzing-a-kernel-mode-dump-file-with-windbg

But analyzing it takes a little more finesse than a per-process level dump.  See how to interrogate all running processing with !process:  https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/-process, etc.


What are best practices for implementing ACL I have a website that has certain menu items that need to be hidden from end users.

The web site has PHP in the front-end and Java and Spring in the back-end, deployed on a Linux OS in a VM infrastructure, although the full technology stack isn't fully understood as it's a legacy system and not fully documented.

I need to secure the site and functions based on access controls - users mapped to groups and groups having access to different menu items (functions). I also have to provide an interface for admins to change the functions-to-group mapping. I also require fine control over the level of different read/write method access.

I understand I need ACL. What is best practice design for such a requirement?

Options and questions:

DB - negative issues would be: old style and creating my own identity management function with all its drawbacks and complexities.
LDAP - negative issues: again my own identity management system, but probably simpler than DB, but I'm not sure how function level mapping to groups works. Do LDAP providers provide mapping of groups to particular functions (i.e. given a menu item "accounts" - I only want Finance to be able to see accounts menu)
OpenAM and similar solutions externalizing Identity Management  – can that work? I've been reading about this – authentication I understand but authorization to fine grain level I don’t. It seems like you need an LDAP product configured as a data source, so what does OpenAM provide over option 2 above because it would be the same? With OpenAM it looks like I configure an identity service but I get to secure at container level – so webserver and app server but it gives its own login page. I assume it's possible to configure that to access stylesheets so that it integrates with the current login page – but  has anyone done that on any of these type of products to be sure it's possible? Also, does this my ACL requirements? Is this the best design and how much more complicated is it to setup compared to LDAP and app configurations?

Further questions:

Is the LDAP solution best advised?
Do you have any suggestions on open source products for Apache LDAP? Are any good/easily managed? Any interfaces possible for manipulation of functions to groups? - Does LDAP allow mapping to a fine grain level of functions/ methods to groups or is that something that is done in application? This part in particular is confusing. If anyone can offer a good resource on this, that would be good.

You need externalized authorization e.g. claims-based authorization (Microsoft-specific) or more broadly attribute-based access control (ABAC).

ABAC was recently defined by NIST and you can download their report here.

In your questions you point to LDAP and groups. You then explain you need to associate functions to groups / roles. LDAP, roles, and groups represent your attributes. They could also come from other sources (e.g. a database). What you're missing is the authorization logic: the mapping between groups and functions.

In ABAC, that logic is expressed as authorization policies. OASIS has a standard for that called XACML, the eXtensible Access Control Markup Language. In XACML, you'll use attributes to define which access is to be allowed or denied.

For instance:

  A user with the role manager and in the group finance can view the finance menu.

You can read more on XACML here and here.


Is it possible to track a missing brand new phone? I ordered a Nokia phone online and it turned out that the packet had been tampered and the phone was missing from the package. Obviously it does not have a SIM card, etc.

I assume someone stole it and is using the phone with a new SIM card. Is there any way that the phone can be tracked ?

First things first.

Since your package was tampered with, I do not expect you to have any details of the phone like the IMEI number, etc. Register a complaint with the website that you purchased the phone from. Even if you go to the police, they are going to ask you to talk with them first anyway. I suggest you talk to a senior customer care executive, which would be more efficient than just sending complaint mail.

Dive right in to the What Next? category. Follow the instructions given by the responsible people. Then file a police complaint if necessary. If you happen to know the vital details such as an IMEI from them, you have some base to search on.

There are many options available online to track a lost mobile phone by its IMEI number. If possible try it with your mobile company. They might have an advanced option to find it.

Failed Delivery:

But honestly, how did you even accept anything that has been tampered with? Even if something like this happens, isn't it a failed delivery and the website holds responsibility for it?

I hope you did not sign the received receipt. If you have, I am afraid that you have no assurance for getting genuine help from the website, or worse, anyone.


Can Facebook break the WhatsApp E2E encryption without the customers noticing? I read a lot of reports from corporate media complaining that you can't censor "fake news" sent via WhatsApp. Mainstream media claims that because of "fake news" the wrong person got elected in Brazil.

At the moment Facebook WhatsApp is E2E encrypted and censorship is not possible. Can Facebook break the WhatsApp E2E encryption without the customers noticing and add censorship? Does an independent security researcher notice if Facebook can read the communications?

Facebook controls everything inside the WhatsApp environment, i.e. the applications on the phones, the web access and the transport of the messages. Because of this it could also make any changes which would decrease the security in a way that the end-user will not notice. It might also make the changes in a way that security experts will not notice unless they really know where to look.

The only kind of guarantee that WhatsApp does not do this is that it markets the E2E security as one essential feature and that WhatsApp will loose a lot of trust (and customers) if it gets public that it knowingly decreased the security. And given that someone has to actually make the necessary changes inside WhatsApp and that these changes will also have side effects of leaking information (because that's the main point they were added) it will likely only be a question of time that it will be known that such kind of backdoors are in the product.


Why HMAC/Signed API requests are not prevalent compared to API keys or JWT based requests While all/majority of AWS APIs requests are signed with HMAC, it is not as prevalent for other APIs in general.
Most likely, the reason is because of the gotchas involved when client has to make the signed API work as they may miss a few headers etc or new headers got added by proxies and so signatures don't match etc.
HMAC signed requests have clear benefits like there will be no secret is in transit and there has to be protection of the secret at rest on both Client and Server, though.
What could be a scenario where product teams should be enforced with signed API requests and not go with API key authentication , otherwise could be a high risk.

Currently industry is pushing towards forward secrecy. The big advantage of HMAC is that if both parties involved agree to exchange them offline then at no point in time will this HMAC be transmitted over the network, this has huge impact on requirements related to secret rotiation amongs others.
One clear advantage you get right away is that you can then generate this HMAC in the HSM (hardware security module) and wrap it for exchange (with key generated by receiving party). Key exchange done this way is generally considered as secure as the underlying system protecting the key (which if done correctly is very strong).
Generally HMACS should be used for high value data. You can take API of financial applications as an example. Both parties must limit their trust as much as possible to avoid possible exchange of sensitive data with possible adversaries.
To avoid any misunderstandings, HMAC does not provide general security on its own, it only takes care of the message authentication which is only a little part of a bigger picture.


How secure is it to send credit card information partially over email and text? I need to pass credit card information for a travel reservation, and I am thinking of splitting it over email and text. The credit card number itself would be send over text, while expiration date and verification number would be send over email. How would you evaluate this technique in terms of security?

Technically not secure, although as a result of a push by Google in the last couple of years, most (90 % ish) server-to-server email relays now use an encrypted connection, but it's still clear text on each server.

If you're going to provide the info, doing so by a voice call is probably as practical as possible.

Since you're already considering email for a piece, I suggest simply encrypting the email.

Ideally all parties would be familiar with using PGP/GPG for encryption, but unfortunately this is unlikely. Instead, put it in a file and ZIP it with a password. Most people know how to handle ZIP files. You still need to deliver the password out-of-band but you can do that with a voice call or depending upon the relationship with a cryptic reference common to you both.


How will security need to be changed if we can crack password hashes in quasi-polynomial time? If we suppose that we have access to some form of generalized password hacking/cracking that can somehow find an n-bit password in time O(n^(log n)), is there need for alarm?

This question arises from some research I'm doing on SAT, the Boolean satisfiability problem.  Another StackExchange question detailing a possible outcome can be found here.  In short, I'm trying to determine if it's possible to solve SAT in quasi-polynomial time.

This question naively assumes that it may be possible to somehow use SAT, along with some suitable transformation of the problem, to hack passwords in relatively the same amount of time.

The time boundary stated above may unfortunately be a fairly naive assumption of the actual performance of an algorithm, which may be able to run much faster in practice.  To get to this point, I am really wondering if we know some sort of threshhold (in terms of speed) where password hacking begins to get dangerous?

I think the best way to answer your question is to say: the premise is highly implausible, so the issue simply does not arise.

I might as well ask: if we suppose that we discover time travel, is there cause for alarm about password security?  Sure, if we discover time travel, someone could travel back in time, appear poof just before I enter my password, look over my shoulder when I typed my password, and poof disappear before I notice.

Or, if my computer can time-travel on demand, I can set it up to iterate the following loop: pick a random password guess, try to see if it is correct, if it is correct print the password and halt; if it is incorrect travel back in time to the beginning of the loop and start over.  If time-travel algorithm is possible, this is an O(1)-time algorithm to crack any password, given its password hash!

But of course these answers are silly, because for the foreseeable future there is no realistic likelihood of anyone discovering how to travel back in time.  Similarly, for the foreseeable future there is no realistic prospect of someone discovering an algorithm to solve all SAT instances efficiently.  Sure, if someone could find a SAT-solving algorithm that could solve every SAT instance in 15 seconds, then they could crack every password (given its password hash) in 15 seconds.  But I don't think that's terribly likely to happen in my lifetime.

P.S. I see from clicking on your link that you would probably prefer a more technical answer.  My suggestion is to read up on Hellman's time-space tradeoff and on rainbow tables; that will give you a better understanding of the state-of-the-art methods applicable to password cracking.  You might also want to read up on why rainbow tables are not applicable to salted passwords; similar reasons are likely to apply to your methods.

Looking at the complexity of the method in your link, I see your method requires a 2v precomputation, where v is the number of variables in the SAT instance.  In contrast, Hellman's time-space tradeoff and rainbow tables require a 2n precomputation, where n is the number of bits of the password (the number of bits input to the hash function).  In the password setting, n is going to be much smaller than v, so rainbow tables and Hellman's time-space tradeoff look like they will perform better than your method.  In other words, it doesn't look likely to me that your method -- even if it is valid -- will beat the state-of-the-art at password cracking or will have much relevance to password cracking in practice.  Of course, you could always try it in a little experiment, and compare your method to existing password crackers; that would be the true test.  But at the moment, I see no reason to expect advances in SAT solving that would be relevant to password cracking.


Why don't PGP and SSH keys see more widespread use as a second factor when authenticating? One of the major up-and-coming MFA methods is U2F, which relies on an initial key exchange and challenge-response mechanism.

It's a relatively new protocol, and is only starting to see more widespread adoption, notably among big web entities like Google, but it's not the first easy-to-use, key-exhchanging, challenge-responding mechanism out there; in fact, two come to mind quite easily:

SSH, which has been around since 1995 and is available on essentially every Linux and BSD box set up since 2000, with growing adoption on Windows via add-on software in older versions and built-in software in newer versions; and
PGP, which has been around since 1991, and is actually included on some of the newer Yubikeys (albeit, controversially, with a closed-source implementation in the latest generation), as well as on millions of PCs worldwide, with plenty of high-quality, actively-maintained implementations and libraries for a slew of OSes.

It seems like it would make perfect sense to use either of these widely-available protocols/standards (respectively) as an MFA mechanism for more than just SSHing into a remote machine or encrypting email; so why haven't either gained any traction where U2F is booming?

Let's check out what PGP and SSH actually offer for this purpose:

PGP:
Client must install PGP software which is not installed by default in the majority of the systems. Client must create a PGP key pair. Then he must send the public key to the server so that the server can use it later for validation. When authenticating with 2FA the server will send a challenge which the client must sign with its private key and send the signed challenge back as response. Of course the client must protect its key against theft, maybe with a password.
SSH:
Client must install the SSH software which is not installed by default in the majority of the systems. Must create key pair and send the public part to the server. When authenticating with 2FA against some web service the client must create a SSH connection to a related server and the server must merge the successful authentication using SSH and the login to the website somehow together, maybe with some additional token the client has to give after using SSH. And oops, there might be a firewall in the way blocking SSH. And of course client must protect key against theft.

Thus essentially both solutions boil down to:

initially install some software
create a static key pair and publish the public part (this might be integrated into the software for convenience but is currently not)
somehow get a challenge from the server and somehow send the signed challenge back. And somehow the server must integrate validation of the challenge into the authentication process. "somehow" because there is no already established process for this which integrates everything with the authentication flow used in web applications.
and of course the client must protect its key

The same procedure can be much easier done with a client site TLS certificate. This still leaves creation of the certificate as a major problem (but this is possible within the browser too today) but at least the validation is integrated into the HTTPS protocol already.

Additionally I cannot see how these solution provide a better user experience or integration experience than existing 2FA solutions. They are not easy to use, require additional software, require new ways to integrate with the server side etc. And they do not provide a better security either. So why care and not take the newer solutions which were designed with usability and server integration in mind?

Apart from that the current cheap 2FA solutions make use of a mobile phone. These provide usually a better security architecture than current PC's. And they are an additional hardware device the user must have access to which makes  the protection offered by 2FA stronger.


Are there any problems associated with using the same encryption key for multiple systems? I have multiple computers, tablets, etc. If I have a very secure key, is there any problem with using it to encrypt all of my systems? I can remember 1 or 2 secure keys without writing them down. But any more than that, I would probably get them mixed up.

There is often a trad-off to be found between security and usability.

Some times you consent to loose a bit of usability for the sake of security. Some times you agree to loose a bit of security for the sake of usability. All that's matter is to clearly understand the risk you are facing and whether or not you accept to cope with this.

In your case:

Using disk encryption is always better than using no disk encryption. Botting from another media or extracting the disk for instance will not give an immediate access to your data.
Using long passphrases is better than short passwords. The disks will most probably be resistant to brute force attacks, an attacker would therefore need to find another way to get access to your passphrases (software weakness, shoulder surfing, hardware keylogger when appropriate are possible examples of alternative ways to get access to your passphrase).
Using the same passphrase on all of your encrypted device make this passphrase o become a single point of failure. If an attacker manage to get access to the passphrase on one device, he will be able to decipher the content of all other devices.

Knowing this risk, you might find it acceptable.

For instance, if all of your device already share the same content (mail software retrieving mails from the same mailboxes, Firefox synchronization enabled, copies of the same files or access to the same shared location (cloud storage, etc.)), then having separate encryption passphrase might be of little value.

Or if your main concern is about one of your device being stolen, the fact that it's content will be strongly encrypted is a sufficient guaranty. A casual thief will most probably have neither the opportunity to look or film you while typing your password nor proceed with an advanced plan like installing some keylogger on your system to capture the passphrases in prevision of stealing the devices as a next step.

I encourage you to check this thread, you will see that a strong passphrase is not necessary a complex one with strange symbols all over the place, and moreover you will discover "@AviD's rule of usability" I have to highlight here:

  Security at the expense of usability comes at the expense of security.


how to protect my USB stick from Viruses I repair a lot of computers with viruses, malware, and what not, and I have one problem that I am struggling to find a solution for. Whenever I connect my USB stick that has the tools I need for the repair process it gets infected and especially the exe files, so after the repair is done i have to scan the USB stick.

My main problem is that sometimes the infections at my USB stick are so bad that I can't disinfect the exe files and I have to copy them all over again. It is very inconvenient since I have around 8GB of programs on it, and copying it all over again is consuming & wears out my USB stick.

I need a solution that would prevent the infected computer from writing to my USB stick in any way. I have had one program that I have had run before I connect the USB to the infected computer and the program would fill the USB stick with empty file so that there isn't any space left to write anything, but that solution isn't good for me since it wears out the stick very fast (it is a Patriot Extreme which isn't the cheapest at the market).

So if you know about a way to protect the USB stick from being written while it is connected to the infected computer, please give me your advice.

UPDATE:

I prefer to use my current USB stick, I know about the hardware slide that some USB sticks and SD cards come with, but I prefer my USB.

Since you don't want to change USB sticks to one with a write-protect switch (don't know why, they're cheap), perhaps you should look into getting yourself a USB write-blocker (aka a Forensic disk controller).

These are generally used by forensics experts when gathering data from a suspect's drive, where they're not ALLOWED to write back to the drive or it will spoil the validity of the evidence, so they have these devices to prevent the computer form writing back to the USB device.

Here's one for example.

  The UltraBlock Forensic USB Bridge brings secure, hardware-based write blocking to the world of USB mass storage devices. The UltraBlock USB Write Blocker supports USB2.0 High-Speed (480 Mbit/s), USB 1.1 Full-Speed (12 Mbit/s) and Low-Speed (1.2 Mbit/s) devices conforming to the USB Mass Storage "Bulk-only" class specification. The UltraBlock USB Write Blocker works with USB thumb drives, external USB disk drives, even USB-based cameras with card-reader capability.


HTTPS client certificates for server-to-server Say you have two servers with certificates proving their domains (e.g. for use with HTTPS).

Can one of these servers use their certificate as a client certificate when talking to the other, so that both servers can be certain of the other's domain name?  E.g. "https://example.com" can get a request that it's certain is coming from "https://elsewhere.com", so can safely send secrets specific to that domain (even if it has never seen that domain before).

(EDIT: I'm aware that client authentication exists in general for TLS, but I'm particularly interested whether the same certificates from the "https" PKI are useable as client certificates.  For instance, usage flags would prevent them from "just working" with existing implementations.)

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.


Is it possible to get hacked if my bcrypt hash is publically known? I just checked https://haveibeenpwned.com/ and I have noticed that I was pwned, therefore I checked the file that hosts the details of my "credentials", however, I see my email in plain text but the password as a bcrypt hash.

Since hash functions are one way and cannot be reversed, should I still be worried and change all my passwords or am I being too paranoid?

EDIT: When I meant "all my passwords" I meant ones that are not closely relevant/similar to the exposed password. Obviously using the same password for almost all websites is quite stupid IMO.

EDIT 2: I would like to ask for all of you to not share any information about how it is done. Thanks for your understanding.

A brief overview of weak hash algorithms vs. bcrypt
With weak password hashing algorithms, what hackers will do is try millions, or billions of different combinations - as fast as their hardware allows for - and many easy passwords will fall quickly to rainbow tables / password crackers / dictionary-based attacks.
Attackers will try to compare a massive quantity of strings to your hash, and the one that validates is very likely your password. Even if it isn't, you can still log in with it because you've found a collision.
However, bcrypt is different. It's computationally slow, so this cracking will be slowed down immensely. Bcrypt can help slow cracking down to the point where you can only do a few tests per second, if that. This is due to the computational cost factor. You should read this answer by Thomas Pornin for a better explanation:

If the iteration count is such that one bcrypt invocation is as expensive as 10 millions of computations of MD5, then brute-forcing the password will be 10 million times more expensive with bcrypt than with MD5.
That's the point of having configurable slowness: you can make the function as slow as you wish. Or, more accurately, as slow as you can tolerate: indeed, a slow function is slow for everybody, attacker and defender alike.

So it really depends on the added computational cost. Some custom hardware solutions are able to crack bcrypt hashes at upwards of 52k hashes per second. With a standard attack, and a poor password, you don't have much hope of holding out for long. Again, this depends on the computational cost: even this custom hardware solution can be forced down to 2-5 hashes per second, or even slower.
Do not re-use passwords if you care about the accounts.

I already found your credentials, and "cracked" your bcrypt hash
But I won't hack you, don't worry. This is just to demonstrate why you should update your credentials, and stop-reusing your password. You wanted an answer, so what better than a live demonstration?
You're from the U.K., correct? Your bcrypt hash is also $2a$10$omP392PbcC8wXs/lSsKZ5Ojv9.wFQ7opUn7u3YUBNu0kkbff0rB.m, correct? I already "cracked" your password, and I know your accounts. I see you, a thief on the roof. My new satellite link has both infrared and the x-ray spectrum. I see your heart beating; I see you are afraid.
This should go without saying: you should definitely change your passwords. Start changing your credentials now... before it's too late. You should be worried, and you should change your passwords. Now.

Yes, bcrypt can be extremely slow, but...
I actually found a way to completely side-step the brute-forcing process with simple data aggregation and correlation. I wrote a little program that ties a few pieces of information together, and compares them. Not a password cracker or anything like that, but at the end of the day, it got the same job done.
For your privacy - and as per your request - I will not share how I did this on here, but you should know that I am not the only one who can do it. If I can do it, so can others.

However... you need to stop reusing passwords!
You really, really do not want to do this. If one site is compromised, having different passwords on other accounts protects the others from breaches as well.
Update all of your accounts, even ones you haven't used in a while, and stop reusing passwords unless you don't care about them. You may want to consider something like KeePass.


Ansible in a cloud image I am looking into using Ansible to manage my systems and going through its documentation I found a recommendation to run the Ansible commands on a cloud image rather than my local laptop.

My understanding is that Ansible basically acts like an SSH user to the systems it manages.  So wouldn't this recommendation mean that I would be storing authorized keys to all my systems (with sudo-enabled users!) all in a single cloud image?

In other words if that cloud image is ever compromised I am royally screwed.

Is this a correct risk assessment or am I not understanding something?

Cloud aside, if Ansible becomes compromised, then it exposes all the servers it manages.

The question becomes: how best to mitigate that risk.

If you use your laptop, then anything you do on the laptop potentially exposes Ansible. Browsing, installing, etc. A dedicated, locked down image that is not used for personal activity is better, in that regard.

Ansible puts all your eggs into one basket and then, to quote Andrew Carnegie, "watch that basket!"


My Laptop has outgoing UDP packets on high numbered ports several times a second I originally noticed this on my router firewall, so I installed Zone Alarm in order to look more closely, and now I can see it in the ZA logs. I have run virus scans from Kaspersky, Trend Micro, & Windows Defender, and the scans all come up clean. I have looked in my program files, my add-ons, and didn't see anything strange. I disabled unnecessary services and tasks, with no change. Does anyone have any ideas on how I can get this off my computer?

Any help would be appreciated. Here is a link to a pic of my firewall log.
http://imgur.com/voNAxWw
Cheers, K

Those UDP packets all seem to go to a public DNS server. Considering the destination port is 53, it is highly likely you are doing DNS queries and not something malicious.


Security behind "Windows Security" Feature Within the Windows Security authentication mechanism active, there are cases the user-login popup comes up.
Are this username and password sent encrypted or they are sent as plain-text as the auth-basic protocol does?

I wrote a more detailed question here:

http://forums.iis.net/t/1226390.aspx?Security+behind+Windows+Security+Integration

becasue this site was not working before.

If I well understood the following answer:

How secure is Integrated Windows Authentication for IIS SMTP?

The fact relies on the protocol that make the request but I doubt if the protocol set at the address bar (http | https) is taking into account when the header("WWW-Authentication") is request. Since that answer was for SMTP I am still with the doubt for HTTP.

Could anybody confirm how secure is it, please? Thanks in advance for your time.

If you have Windows Authentication on IIS you are effectively allowing the following protocols:

NTLM
Kerberos
Negotiate - which automatically chooses one of the above to use.

If it is your internet users that are getting the prompt, it is most likely that they will not authenticate with Kerberos unless you have internet facing authentication and ticket granting servers. Therefore the response derived from the NTLM hash will be sent over the wire as cleartext. This does not expose the password itself though, but the challenge/response can be sniffed. It would also be possible to intercept and/or modify the session whilst in transit.

To secure this you should implement SSL/TLS so that your server encrypts the connection - it will have a HTTPS URL. This will prevent any eavesdroppers or Man-In-The-Middle intercepts of the connection and authentication data.


If you want to implement a XSS scanner, is it absolutely necessary to use a JS interpreter? Why? In a recent discussion about a security vulnerability scanner that returns false positives for XSS detection, I noticed that the scanner just inject a string like "this_is_my_string_" (without the double quotes) and if it sees the string in the HTML response it says that there exist an XSS.

Talking with the author of the scanner, I asked him how it is possible to say that there exist an XSS just inserting that kind of string without < > ' " or any special char (just _). He says that as the scanner does not still include a JS interpreter and the detection will always be unreliable and manual confirmation will be needed.

Is it absolutely necessary to use a JS interpreter to detect automatically XSS vulnerabilities?

Will it be very unreliable to insert the called XSS locator 2 of the OWASP:

'';!--"<XSS>=&{()}

and look for special chars not being encoded in the response? Why?

Reliably detecting Cross-Site Scripting is a relatively complex task, just inserting a string with no control characters and looking for it in the response, is a very bad idea as you'll be swamped by false positives.

What most scanners to is take a series of standard vectors (e.g. ">< script >alert(1)< /script ><") and then look at the response from that string unencoded.

Even then this is not perfect as it depends on the context of the response as to whether it's exploitable.

A better way of handling this is to actually look at the DOM of the resulting page and look at the JavaScript executed on page load to see if your vector has been included in an executable location.  This obviously requires an HTML rendering engine and a JavaScript rendering engine.

Also there's the problem of following links if the scanner includes a spider to find content.  Without a JS interpreter the spider will likely miss links that can only be followed by evaluating JavaScript, of which there are a lot these days.

So the answer would be that a JS interpreter isn't an absolute requirement but it will help a lot.


Penetration testing against an ignorant target - Is it legal? I know it's a big no-no in terms of etiquette, but is it illegal in Canada to perform penetration testing against a commercial company without authorization?

prompted by: http://news.nationalpost.com/2013/01/20/youth-expelled-from-montreal-college-after-finding-sloppy-coding-that-compromised-security-of-250000-students-personal-data/

P.S. My understanding is that he could probably be charged under a number of articles (most of which aren't specific to the IT realm).

Since we are not, and do not aim to provide, legal advice (since we're not lawyers) this is a really hard one to talk about. That being said, it is generally considered a good idea to obtain written permission from the organization, signed by someone within the organization who is authorized to sign such things, permitting you to perform any kind of scan or penetration test. Without that authorization there is a very fine line between "I was checking to see if the fix had been made without malicious intent" and "I was checking to see if the fix had been made with malicious intent".

Within Canada the most likely relevant portions are going to be Section 184 and Section 342 of the Criminal Code of Canada. I won't attempt to interpret the contents, since quite frankly I'm scared of the potential of accidentally giving legal advice.

The short of the matter is that whether or not the kid was criminally liable for what he did he was, in my opinion, a fool for not obtaining permission before conducting a vulnerability assessment/penetration test.


Can we detect malicious redirections by retrieving the webpage's headers? Is it possible to know if there are URL redirections (to malicious websites) by retrieving the   HTTP request and response headers of the legitimate website   ?

The redirection can be performed in various other ways (like JavaScript) which will not involve sending any headers. So no, headers are not a reliable source.