Do Chrome/browser extensions break the tab sandbox?

Access to privileged methods in a Chrome extension depends on two factors:

The active extension permissions.
The current process.

Chrome extensions can only request access to privileged APIs after declaring the necessary permissions in the manifest file. There is also a set of private APIs that are only available to an extension when their extension ID is whitelisted (hardcoded in Chromium's source code). This is not really relevant if you want to escape the sandbox, it just defines the boundaries of the impact of a compromise.

There are two "sandboxes". One that is visible to extension developers, that aims to protect users from websites that try to leverage the privileged extension methods. The other one is transparent to extension developers, and provides protection against compromised (render) processes.

Chrome is a multi-process application, consisting of one (high privilege) browser process, and multiple render processes. Each tab/site runs in its own process see Process Models for more details, with the minimal privileges necessary to execute their task.

Extensions can use so-called content scripts to modify the appearance or functionality of websites. These content scripts share the same process as the website on which they are acting, but the JavaScript code runs in a separate context. This allows the extension system to offer a very limited set of privileged JavaScript methods to the content script, e.g. in form of the extension message passing API and cross-origin AJAX. When a tab process is compromised, the damage is limited. It could make cross-domain requests (if the extension had the permission to do so) and send messages to the extension's background process, but not read files from your filesystem, nor use any of the more powerful extension APIs. When one tab process (renderer) is compromised, the damage is usually limited to that single tab/origin, thanks to the security architecture.

Other parts of the extension (e.g. background pages, popup pages and pages where the omnibox displays chrome-extension://[EXTENSIONID]/...) run in the extension process. Pages within the extension process can use powerful APIs provided that it has requested permissions to use them, including read access to files on your local file system (provided that it has requested access, and you have explicitly put a tick at the "Allow access to file URLs" checkbox at the extension settings page - this does not happen by accident, don't worry).
When an extension process is compromised, the damage is limited to what an extension can do. It cannot write to arbitrary files on you file system, for instance.

(note that a malicious extension developer does not need to go into the efforts of compromising an extension process, because if you install a malicious extension that requests the "Access your data on all websites" and "Access your tabs and browsing activity", then it already has sufficient power to mess with your websites, e.g. by stealing passwords when you type them).

External resources

http://www.chromium.org/developers/design-documents/process-models
Describes the different process models that Chromium supports for creating renderer processes.
http://webblaze.cs.berkeley.edu/2010/secureextensions/
Describes how Chromium's extension system is designed from the security-first approach.
http://seclab.stanford.edu/websec/chromium/
Describes Chromium's security architecture (not just extensions, but the browser as whole).
http://www.chromium.org/developers/design-documents/site-isolation
Site isolation (not extension specific, but relevant for the security assessment of content scripts)


WinHTTP - Prevent successful handshake if peer certificate is invalid

Question; For security compliance (FIA_X509_EXT1.1), should connection terminate right after SSL handshake? Incase peer certificate is deemed invalid. Or is this ok to terminate later?

TL;DR: I don't think failing in TLS handshake is an actual requirement. But it will be much harder to prove secure behavior if it does not already fail in the TLS handshake.

I cannot see anything in FIA_X509_EXT1.1 and related which explicitly requires the client to already fail inside the TLS handshake. And from a security perspective it should not matter if the TLS connection fails inside the handshake or after the handshake as long as no application data get sent by the client over the untrusted connection or server data get processed. This means that as long as the certificate of the server is not fully validated:

The client should not sent any application data to the server.
The client should not process any application data sent by the server.

If the client fails the TLS handshake already in case of a bad certificate this is easy to show because application data can only be sent and processed after successfully completing the TLS handshake. But, if one allows to fail the TLS connection only after the TLS handshake then one needs to have a closer look at the specific application behavior and also the upper layer protocols.

There are protocols like FTPS, SMTPS ... where the server sends data before the client. In these cases one might actually see application data from the server in the packet capture even with bad certificates since the TLS handshake got completed successfully from the perspective of the server. Thus one needs to show somehow that the client did not process these (untrusted) data which would probably involve to dig deeper into the clients and/or TLS stacks source code.

In other protocols like HTTP the client sends data first. In these cases no application data should be seen in the packet capture at all if the certificate validation should fail.  But, one would probably still need to analyze the case where a server is not conforming to the protocol and sends data to the client. Here one also needs to prove somehow that the client does not process these untrusted data from the server.

In summary: I don't think it is an actual requirement that the TLS connection should fail already inside the handshake if the certificate cannot be validated. But, if the TLS connection only fails after the TLS handshake is completed it will be much harder to verify that the no sensitive data got sent over the untrusted connection and that no untrusted data got processed by the client.


Per the Yubikey FAQ they state the following:

  ..."All YubiKey NEO devices manufactured as of February 10, 2015 supported the current FIDO U2F specification for NFC. To verify you have a YubiKey NEO that supports NFC, check to see your YubiKey is running firmware version 3.4.0 or later."...

Likewise, the YubiKey 4 (v4) and Neo (v3) are also listed as being FIDO certified U2F authenticators

Based on the YubiKey FAQ it appears either a hardware or firmware change occurred in their product line near the February 10th, 2015 date and that may be the cause of conflicting information you are running into.


a) is clear: if the outsourced service is the scope of their certification then you can offload to them.

b) and c) are the same from a pure ISO perspective: they are not certified and it is up to you to ensure that this part is appropriately covered.

Appropriately means that you have assessed the risk and acted upon it (accept, mitigate, insure). How you do it is up to you (and will be hopefully agreed upon by the auditor), this may include contracting the existence of their audit results (an SLA would be part of the contract), or the ability to perform your own.


Do mobile apps have their own certificate store?

The short answer is that it depends on the application's implementation. Certificate pinning is not a default, it is rather a custom implementation. Default is to rely on system trust store - on iOS as well as Android.

In general the security best practice is to use SSL pinning. Pinning could be implemented in two ways - Including the entire certificate store to the client package  or by including the signature for a certificate to the client package. You shall be able to verify this by reversing the client package.

Similar to the way most desktop applications work, mobile applications also by default rely on the trust store provided by the operating systems. On Android OS's before Android 7.0, the user could install a custom certificate to the system trust store from an SD Card. This resulted in trivial MITM attacks and the capability has since been removed from later versions. Applications no longer trusts user installed certificates on android devices.


Cookie Based Authentication
Pros

HttpOnly Flag: Session cookies can be created with the HttpOnly flag which secures the cookies from malicious JavaScript (XSS-Cross-Site Scripting).

Secure flag: Session cookies can be created with Secure flag that prevents the cookies transmission over an unencrypted channel.

Cons

CSRF: Cookies are vulnerable/susceptible to CSRF attacks since the third party cookies are sent by default to the third-party domain that causes the exploitation of CSRF vulnerability.

Performance and Scalability: Cookie based authentication is a stateful authentication such that server has to store the cookies in a file/DB in order to maintain the state of all the users. As the user base increases the backend server has to maintain a separate system so as to store session cookies.

Token Based Authentication:
Pros

Performance and Scalability: Tokens contains the metadata and its signed value(for tamper protection). They are self-contained and hence there is no need of maintaining state at the server. This improves the performance and thus scalability when the expansion is required.

CSRF: Unlike cookie-based authentication, token-based authentication is not susceptible to Cross-Site Request Forgery since the tokens are not sent to third party web applications by default.

Cons

XSS: Since the session tokens are stored in the local data storage of the browser and it is accessible to the JS of the same domain. Hence there is no option to secure session identifier from XSS attacks unlike HTTPOnly security flag which is available in the cookie-based authentication.

Conclusion
Both of the mechanisms have their own pros and cons as mentioned.In the present era of Application Development Frameworks, cons such as XSS and CSRF are taken care by the underlying framework itself and hence I feel it is without a doubt a clear trade-off on which developers and the stakeholders takes the decision.


What is the purpose of these hacking attempts on my Plesk VPS via postfix?

To quickly run through the log lines, anything with postfix/ in it relates to your SMTP server (the server responsible for sending/receiving email, where e.g. IMAP presents email to users).

The other lines, relating to plesk_saslauthd, are from your authentication backend for postfix.

So:

Apr  3 18:11:26 myvps postfix/smtpd[12561]: warning: hostname vps863.hidehost.net does not resolve to address 91.200.12.150: Name or service not known
Apr  3 18:11:26 myvps postfix/smtpd[12561]: connect from unknown[91.200.12.150]

A connection to postfix (presumably on tcp/25) was made by a server at 91.200.12.150 (which doesn't have a proper A/PTR pair, and claims to be part of hidehost.net)

Apr  3 18:11:26 myvps plesk_saslauthd[12563]: listen=6, status=5, dbpath='/plesk/passwd.db', keypath='/plesk/passwd_db_key', chroot=1, unprivileged=1
Apr  3 18:11:26 myvps plesk_saslauthd[12563]: privileges set to (103:113) (effective 103:113)
Apr  3 18:11:26 myvps plesk_saslauthd[12563]: failed mail authenticatication attempt for user 'auditor' (password len=9)

That connection attempt was followed by an attempt to login as user auditor, and after plesk_saslauthd spawned a process to deal with it, that attempt failed.

Apr  3 18:11:26 myvps postfix/smtpd[12561]: warning: unknown[91.200.12.150]: SASL LOGIN authentication failed: authentication failure
Apr  3 18:11:26 myvps postfix/smtpd[12561]: lost connection after AUTH from unknown[91.200.12.150]
Apr  3 18:11:26 myvps postfix/smtpd[12561]: disconnect from unknown[91.200.12.150]

Postfix is told this user failed to authenticate, reports as much to the 'client', and the client disconnects.

Apr  3 18:11:56 myvps plesk_saslauthd[12563]: select timeout, exiting

The process used to check the credentials supplied during the connection exits.

The main things you should be concerned about are:

not allowing any important accounts to be bruteforced by repeated, unlimited attempts
ensuring insofar as possible users choose good passwords.

As for your other concerns, there isn't enough log to say if your service can be abused.

As @dandavis mentions, this happens all the time, so making sure you have followed any applicable best practices (OS, Plesk, and individual services) is probably a good thing.


What determines the type of HTTPS indicator shown by Chrome?

Many web browsers now will differentiate the "padlock" placed beside a web address when the website uses different types of SSL/TLS certificates. These certificates are used to generate a secure session in which data is encrypted between your browser and the destination web server.

The example you have provided is a difference between eV (extended Validation) and "regular" certificates.

In the case of eV certificates, there is a much more rigorous, and in depth procedure when obtaining such a certificate. Company information and owner information are examples of details required in a eV certificate. It allows visitors to identify the website, and verify the company who holds the certificate, is in fact the one running the website. Owner information and such are not required when requesting a "normal" SSL/TLS certificate.

Firefox makes a bigger differentiation for eV certificates, where a simple green padlock is replaced with a wider green bar containing the company's name and country abbreviation (US/CAN/UK).


Is there any open source TestSuite available to test TLS Server/Client software?

For the validation of the server I use https://github.com/drwetter/testssl.sh, it gives you a lot of information of security issues from my point of view


Proxy rewrite entirely the packets, so depending of proxy's configuration, anything is possible. So, the proxy is doing the ssl connection to the server and is serving you a non-ssl webpage. Maybe is only a cached webpage. Did you try to do some searches on google? Try to search something "weird" what it's suppossed to be uncached to sse if http remains, if yes, it confirms is not only cached web pages but sslstripping.

Is a trusted network? if not, don't surf the web there because your passwords and credentials can be intercepted in plain.

A proxy combined with DNS can bypass HSTS. It's called sslstrip2 or sslstrip+. Look at this or this


Do `sudo` and `su` belong to capability-based security?

In fact, the sudo and su programs are not parts of either security model for several reasons.

Protection rings are referring to the memory/CPU access permissions and in the user-space the only access is to files.
Capabilities refer to process permissions and as independent programs they are a separate process than the caller and do not inherit or give away any of their capabilities onward.
They are independent software programs that are not affected or affecting the OS in any way.

Some background may be relevant here:
In Unix and Linux there are two levels of permissions: standard user and superuser (usually called root).
The standard user has access only to the files that he has permissions for, by ownership, group membership or ACL.
The superuser has permissions to everything (we'll ignore stuff like SELinux and the like for this answer) without limits within the userspace.

This presents a major hurdle to overcome, since a standard user doesn't have access to system files how could something like a password change be performed? For a password change, the user must write to the /etc/passwd or the shadow file (it's location varies between different Unix flavors).

In order to support this and similar cases, Unix systems have introduced a way to grant special permissions called the suid bit. This is a bit in the filesystem that when set on an executable allows it to gain the privileges of the file owner rather than the calling user.

Sudo and Su use this mechanism to allow a user to set it's effective permissions to those of someone else (usually the superuser, but not always) so they can run normal programs that do not have their suid flag set, as a user other than the one they logged in as.


is_correct_answer should be a public static final boolean member of an instance of a Class; something like a Question class, as opposed to a variable that gets reassigned a value more than once.

Beyond that, If this is a native Android (non-webview) application, it appears to be quite involved and difficult to alter client-side runtime values, where a user would have to alter the value stored at that memory address.

I came across some interesting approaches, attack surfaces, and more that you may want to consider at https://hackerbot.net/mobile/android


Can someone using Wireshark obtain the full URL if my program uses HTTPS?

With HTTPS the path and query string of the URL is encrypted, while the hostname is visible inside the SSL handshake as plain text if the client uses Server Name Indication (SNI). All modern clients use SNI because this is the only way to have different hosts with their own certificates behind the same IP address.

The rest of the URL (i.e. everything but the hostname) will only be used inside the encrypted connection. Thus in theory it is hidden from the attacker unless the encryption itself gets broken (compromising the private key, man-in-the-middle attacks etc). In practice an attacker might have indirect ways to get information about the remaining part of the URL:

Different pages on the same server serve different content with different sizes etc. If the attacker scans the site to find out all possible pages he might then be able to find out which pages you've accessed just by looking at the size of the transferred data.
Links to other sites contain Referer header. Usually the Referer is stripped when linking from https to http, but if the attacker controls one of the sites linked with https he might be able to find out where the link came from, that is the site you've accessed.

But in most cases you are pretty safe with HTTPS, at least much safer than with plain HTTP.


Defining what you mean by "malicious", what you mean by "investigate", and who is doing the investigating are all important.

If you need to determine if the site is hosting malicious code, then you need to run a malware scan on the URL. There are many online sites that can do this for you (as well as the AV on your machine). VirusTotal is a big one and probably the most famous. It will give you an opinion that the average user can understand.

There are also sandboxes that you can set up that inspect what the code on the linked site does so that you can do an in-depth analysis on the site yourself. This is not for the average user.

Phishing defense sites, like PhishTank, will help you look up to see if the site has phishing markers or if the link has been reported as a phishing site by the community.

There are also various reputation ranking sites and URL blacklist sites that allow you to look up how "dodgy" a site is based on its past behaviour.

For shortened URLs, you can use a URL de-shortener to find out where the link actually goes to then feed into the above.


Is it dangerous to keep permissions at 666 to member file on SELinux?

SELinux contexts come in addition to permissions and ownership. In order to access a file, a process needs to have the privileges given by ownership and to pass the checks made by SELinux. To take an extreme example, it's possible to create a root account (user ID 0) on a machine where SELinux confines this account so much that it can't make use of root privileges for anything. A file with permissions 666 but an SELinux context that prevents access is perfectly safe.

This doesn't mean that relying solely on SELinux to control access is risk-free. It's perfectly fine as long as the file isn't changed, but if the file is edited, or copied, or backed up, or otherwise affected by a tool that doesn't support SELinux then the SELinux context could be lost. Furthermore SELinux is notoriously hard to configure correctly; permissions are a lot easier to understand and audit. You should treat it as a second line of defense.

In the case of /selinux, that's a special filesystem which exposes information and controls related to the SELinux configuration. It's designed and populated by the people who make SELinux, so the risk that it's misconfigured is very low. It isn't going to be backed up or edited. So the risks of SELinux lack of support or misconfiguration do not apply. /selinux is part of how SELinux works and is not dangerous.


Let it be banned. Unless you're a large company that has to worry about things like google e-mail servers IPs getting through, there's not much for you to worry about. abuse happens everywhere, including MS and Google. They should deal with it.


Securely read encryption key from NVRAM of TPM 1.2

I don't think this problem can be solved, as someone capable of soldering wires to the LPC bus can solder them to the memory modules and get the keys from memory.

The best alternative I know about is to simply keep the keys separate from the machine, like on a flash drive and only connecting it when necessary after making sure the machine hasn't been tampered with. That way, someone stealing the machine has no way of decrypting its storage, no matter how hard he tries (excluding quantum computers).


How can I secure a NAS on my home network?

You are absolutely right to be concerned. Ransomware is increasingly prevalent and totally devastating if you are not prepared. Once you make the storage accessible to any client, it is going to be vulnerable and there is little you can do to change that I'm afraid.

Generally, as Marcel commented, there are two things you need to do:

If you can (I couldn't see the feature on the D-Link site), have versioning turned on.
Have remote backups with versioning

Versioning

File versions would allow you to roll back any changes and recover deleted files and would be a quick way to be able to recover if ransomware encrypted files for example.

Backups

Backups must be to an offsite location. They must be automatic, encrypted (preferably locally before sending) and should be versioned since it is is likely that you will have backed up several times before you discover an issue.

Local backups are useful for quick recovery but are worthless for long term information security since a local disaster, burglary, etc will wipe out the backups along with the originals.

Use a cloud backup service or at least have another unit at someone else's house.

If your information is in any way important to you, good backups are utterly essential.

If you are not able to follow this advice, at least make occasional copies of key files such as family photos, financial information, etc. Even the old standby of a DVD or similar that you then take offsite to a friend or family house is better than doing nothing. But with manual backups, you will eventually loose data since you will forget to backup something important.

Of course, you should take precautions on your PC too, AV, latest updates and adblocking all help reduce the risk. You might also want to save up and upgrade your router to one with a decent firewall capability.

UPDATE: So backups are the most critical thing you need to do regardless of where you are keeping files. Once you've dealt with that, you will find that the better NAS's such as the Synology ones are "simply" low-power Linux computers. As such, they should (Synology certainly do) give you access to the Linux firewall. So you can further protect the NAS by limiting the access to it. How you do that would be the subject of another question though if you check my recent answers to other questions you may get a clue or two ;-)

To protect your PC, again versioned backups are the key. You can back up to the NAS or direct to cloud. If you discover malware, disconnect from the network immediately to limit the damage.


Does someone have it out for me, or is this router "features"?

I found out the problem several months ago. I had a lot of scripts which were downloading data. When the Internet was breifly unavailable these scripts had the curl -retry flag set to 5. Due to the nature of curl delaying the retry exponentially, it created a fork bomb which in turn crashed the network stack. -retry was set to 0 and the problem resolved it's self.


pubring.gpg and pubring.gpg~ at install - why?

The tilde is a common suffix for file backups.

This file is a backup of your public keys, used by GPG to avoid corrupting your keys when you modify them.

You can safely delete it, but it will be recreated the next time you use the program to modify the pubring.

Source.


Using NameConstrains in a CA certificate

Pretty sure it should be

DNS Name=.valid.com

to allow the subtree.

https://www.sysadmins.lv/blog-en/x509-name-constraints-certificate-extension-all-you-should-know.aspx has more information.


You want the key recoverable upon reboot and without a user present, so proposing to encrypt it with a user password and store it in RAM goes against your requirement for a recoverable key. So, encrypting it with user password is a non-starter. Let's reject that proposal.

Instead, we will need to store it in a recoverable form (i.e. in plaintext or encrypted with a key which then needs to be stored in a recoverable form). That is, we have a recursive problem - one without end. I realize you really, really like your idea and are asking a lot of different questions in order to solve the problems you have. I think that's fantastic.

However, the problems won't go away. I refer you to the answer in this exchange sub-titled "Conceptual Problem" in which is described the concept: We cannot protect a computer from itself.

This section makes it clear that if you wish to have a standalone machine recover its own key (or credential) without human intervention, you cannot prevent its theft from allowing it to be used elsewhere.


Recovering NTFS encrypted files from a USB drive on a different machine

Provided you are using the native in-line encryption provided by Windows, the only way to recover them is to obtain a copy of the original encryption keys. These are notably not based on your password/PIN (though they are encrypted by a master password secured by your login credentials). Windows provides an option to export these security keys in PKCS#12 format for backup purposes (and will usually nag you about backing them up until you either do so or explicitly turn off the nag notifications).
Without these encryption keys, there is no realistic way you can recover the file contents, as the encryption methods used are sufficiently secure to protect against most attacks.
Unfortunately, as you reinstalled Windows 10, you no longer have access to these keys unless you had previously backed them up somewhere else.


SSL certificates for a mixture of subdomains and top level domains

All of these approaches are technically feasible, i.e. they can be generated and browsers will accept these. But while you can create such certificates using your own CA it does not mean that every CA will support issuing all of these variations.

In case of using a single certificate for each different name you have to make sure that either each of these names points to a different IP address or that your server and client both support Server Name Indication (SNI). While this is true for all modern browsers and web servers you might get problems with older browser or applications or with protocols outside HTTP.


Windows 8 in a VDI environment and the use of Secure Boot

A virtualised environment could would be easier to handle in this case.

Firstly, in order to load any operating system, you need to emulate boot. So a VM implementation such as Intel VT only implements CPU emulation; the rest is up to the vm software. Everything must either be emulated or passed through with hardware support.

Boot is no exception - and as most VM solutions currently emulate MBR-based BIOSes there is no reason for them not to be able to emulate EFI boot either. The EFI spec is publicly available and GPT-partitioned disks such as are required to EFI boot with Windows have been creatable for a while now.

Now the question is - how does secure boot work? Well, without diving too deep into the specification, the concept is that the binaries you wish to boot are signed with a private key and the corresponding public key is shipped with the hardware. I'm not yet sure to what extent a full x509/PKCS trust chain is in place, but I believe that's the aim.

Given an executable the hardware is asked to boot, secure boot means very simply that it will check the signature(s) on that executable and if they match its internally trusted certificates and the signatures remain valid, great, they can boot. If not, the EFI shell simply tells the user "sorry mate, can't boot that, don't like it" and bam, out you go.

So from the point of view of guest operating systems, life is easy getting things to boot - just allow it and don't check the signatures.

Things get more complicated when it comes to the OSes ability to establish a channel* to the hardware, however - I believe (I've not read that bit of the spec thoroughly, but I have read the GPT layout part. I can quote GPT layouts to you in my sleep!) operating systems will communicate with the EFI shell should they wish to notify it of changes to their environment, replace keys etc. This would need to be emulated correctly; a failure to do so would undoubtedly break the host OS assuming it requires and expects the protocol to exist.

If Windows 8 is going to insist upon secure boot and the ability to interact with the hardware, that'll all require correct emulation. However, OSes that merely require getting started it'll make no difference to.


How do I verify someone's identity if the only method of contact is their email address?

"Remaining anonymous" and "verifying identity" are contradictory, aren't they?  I would say if you want to pay someone and guarantee that they get the money, they can't remain anonymous.

  If I ask them to give me a personal password and in return I give them each a unique public key, will that be enough to verify their identity assuming they took precautions to remove the email with the public key and place the key in a secure place?

I see a few problems that might come up:

how would they give you the personal password if not by email? I guess you should better describe where you are starting from with them.
deleting the email immediately does not guarantee safety.
Compromised email accounts can be set up to forward emails to other
accounts.

Usually what you want to achieve is done by communicating the "key" in an out-of-band method such as SMS.  Those who don't want to divulge their number will just have to take the risk of losing their money, I guess.

  If it fell into their hands it would put lives at risk.

That escalated quickly... you will have to explain more the threat you are really guarding against if you want a more helpful answer!


Bypass directory traversal filter in PHP?

It is indeed way too simplistic. You can bypass it using a backslash character.
Example of a way to bypass it on my IIS server:
http://example.com/index.php?doc=..\/index.php

It checks for "../" while, in order to make it "safer", it should check for ".." or don't allow any dots at all and make sure it's only included in the extension of the file requested.


How to prevent CSRF if you want to include Flash plugins in your form like Uploadify in your form?

CSRF or Cross-Site Request Forgery is basically a bad person tricking a good person's browser into performing functions on your website on the bad persons behalf.

Here is an example:

  Good user logs into your website and
  obtains a valid session
  Bad user tricks good user into
  following a link to a malicious site
  Malicious
      site contains a form with falsified data which posts to your
  website
      (however since it's sent from client
      side, your site thinks it originated
      from the good user)
  Your site then
      see's the good user submitted a form
      and processes the action.

Let's put it into context:

  Good user is an administrator on
  your website.
  From the admin panel, good user can
  add a user by filling out a form
  that looks like this:

<form action="/new_user.php" name="myform" method="POST">
    <input type="text" name="new_username">
    <input type="password" name="new_password">
    <input type="Submit">
</form>

  Good user follows a link to a
  malicious site, which contains the
  following javascript:

<form action="http://www.yoursite.com/new_user.php" name="myform" method="POST">
    <input type="hidden" name="new_username" value="MaliciousHax0r">
    <input type="hidden" name="new_password" value="MaliciousPass">
</form>
<script type="text/javascript">
    document.myform.submit();
</script>

  Your application now receives the
  request which was submitted by Good
  user, on Bad user's behalf. Since it
  originated from Good user, who
  happens to be logged into your
  website, all is well and your
  website processes the request.

  Now keep in mind this is a simple
      example, and the Good user would see
      the submit happen which SHOULD raise
      a red flag, however using slightly
      more complex methods, such as
      XMLHttpRequest() in javascript would
      be silent/unknown to the Good user.

  Bad user has now obtained an account
  on your system.

How to eliminate CSRF:

  The trick is to add a token to each
  form that has a random value which
  is generated for each request.
  When the form is submitted, your
  application checks to make sure the
  token is passed, and matches the
  random one which was generated when
  the form was loaded.

  The malicious site wouldn't have
  access to this token, therefore it
  wouldn't be able to provide that
  required peice, and a form submission
  would not be processed.

How to make other tools work without disabling CSRF protection in CakePHP:

I don't know. Check documentation for the CSRF protection, for CakePHP, and for the other addons.

Question whether or not using those addons is worth the loss in CSRF protection, and consider alternate solutions.

CSRF Resource:

https://www.fortify.com/vulncat/en/vulncat/javascript/csrf.html


Erasing a hard-disk, encrypting it as alternative?

Modern research seems to indicate that performing a single zero-pass of a hard drive is sufficient for most data dispositions. In which case, no, performing a file or partition encryption would not be faster. Except in the case of hardware accelerated encryption (such as the newer Intel i series processors) encryption speed is CPU bound, whereas a single zero-pass would be I/O bound. Even in the face of hardware acceleration, we still run into the problem of performing an I/O bound function, making it no faster.

Sometimes there are specific policies, laws, or regulations that require something more stringent. In these cases you will often have very specific disposition requirements, which you should be following anyway.


Is it harmful to allow http requests with very long querystrings in IIS?

15,000 character URLs isn't going to work very well cross-browser: https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url

Assuming you already know that, in an ASP.NET application, a 16,000 character limit will increase your vulnerability to request-queue-buffer exhaustion attacks 8x. Now, 8x is not that significant compared to better DoS attacks generally open on an ASP.NET website.

Regular expression matching is not probably a big issue. Most regexp attacks work equally well with 64-character and 64,000 character strings - they exploit an exponential backtrack pattern, and your request timeout makes the URL length quite unimportant. On the upside, most of these kinds of issues will show themselves quickly in performance issues. Also, regexes generally are only applied to the path, not the querystring.

Path regexes are generally quite fast and usually exit the match at the first integer comparison, although there are exceptions.

If you raise the limit, just ensure all URL rewriting, routes, path matching, and pre-HandleRequest events are efficient, have fast exit paths, and don't do any high-latency work like disk or db access.


Microsoft recommended patching period - Security Patch release and updates

Microsoft have been telling us for a while that most customers no longer bother to test patches.

The reason is that the cost of testing so many patches so regularly is prohibitive compared to the very low risk of patches causing problems. This is especially true now that patch release cycles are so short since a faulty patch can often itself be patched in less time than it would take for you to test it.

So nearly everyone now just applies Microsoft patches as they arrive - we do that, simply spreading the load of the patches over a few days to even out performance over the network.

The same cannot be said for some other vendor's patches. Java is the obvious one that springs to mind!


Could it be possible to hijack physical finger prints in digital form and use them to gain access to other devices and locations?

Here's a relevant section of Apple's "iOS Security" document:

  The fingerprint sensor is active only when the capacitive steel ring
  that surrounds the Home button detects the touch of a finger, which
  triggers the advanced imaging array to scan the finger and send the
  scan to the Secure Enclave.

  The raster scan is temporarily stored in encrypted memory within the
  Secure Enclave while being vectorized for analysis, and then it’s
  discarded. The analysis utilizes subdermal ridge flow angle mapping, which is a lossy process that discards minutia data that would be required to reconstruct the user’s actual fingerprint. The resulting map of nodes is stored without any identity information in an encrypted format that can only be read by the Secure Enclave, and is never sent to Apple or backed up to iCloud or iTunes.

To me this implies that the fingerprint never actually passes through the standard iOS memory, but rather directly to the secure enclave. Once it's in the secure enclave, it's transformed in a way that the fingerprint cannot be reconstructed. So on Apple devices, this does not seem to be possible even on jailbroken devices, except maybe in the case of an attack on the physical hardware.

Other devices such as Android are different. I believe Google has design guidelines similar to Apple's but manufacturers do not need to follow it exactly. I'm fairly sure that some early Android devices simply encrypted finger print data in the standard storage, but I'll look for a reference as I could be wrong.

Edit:

https://www.extremetech.com/mobile/211985-htc-caught-storing-fingerprint-data-in-unencrypted-plain-text
https://www.blackhat.com/docs/us-15/materials/us-15-Zhang-Fingerprints-On-Mobile-Devices-Abusing-And-Leaking-wp.pdf


Creating a system to try new software out

I would definitely recommend using a Sandbox.

Taken from Wikipedia :

  In computer security, a sandbox is a security mechanism for separating running programs. It is often used to execute untested code, or untrusted programs from unverified third parties, suppliers, untrusted users and untrusted websites.1 A sandbox typically provides a tightly controlled set of resources for guest programs to run in, such as scratch space on disk and memory. Network access, the ability to inspect the host system or read from input devices are usually disallowed or heavily restricted.

  In the sense of providing a highly controlled environment, sandboxes may be seen as a specific example of virtualization. Sandboxing is frequently used to test unverified programs that may contain a virus or other malicious code, without allowing the software to harm the host device.2

A very good program for this would be Sandboxie which can be found to download from here.

A good tutorial for using Sandboxie can be found here.

Good luck and happy testing! =]


For maximum security type this command.

# sudo ifdown eth0

But for real.  The answer in this thread is almost exactly what you are looking for.
How do I run a security check on my WordPress server?

edit:  Oh I realized that it was YOU who asked that question...

Firewall rules using iptables.  Only leave open the ports you need.  Block all, allow port 80 for example.
Change default passwords.  If you want to know how a lot of people get hacked...default passwords are a main reason.  Change it to your mysql server, your user accounts, whatever.
Disable services you don't need.  Hell, uninstall them.
Run up to date software.  The reason wordpress will update sometimes is because an old version may have a vulnerability. Make sure your services are all up to date.

If you do this stuff well....you should be pretty secure.


What is the correct way to implement anti-CSRF form tokens?

There is a good explanation on OWASP: OWASP CSRF Prevention Cheat Sheet

In short they say that there are two ways:

Add a random token to each user session. Only if this token is present and correct will the changes be applied, otherwise the request should be rejected. It is important that the token is only sent with a POST request, since GET requests can leak the token to different places (browser history, log files, etc.).

It is also possible to generate a token per request, but this leads to usability problems. For example the back button wouldn't work properly anymore. But of course the security would be increased.

Also make sure (to enhance security even more) that the token is only sent over TLS, so there won't be any man in the middle problems.
The other option is to use some sort of challenge - response (for example CAPTCHAs or one-time tokens).

The OWASP-Page also lists a few measures that don't work. These are

Using (secret) cookies
Not using GET-requests
Multi-Step transactions
URL Rewriting


My issue ended up being a misunderstanding of the correct way to enumerate memcached. I was pointing my netcat, nmap, whatever tools at the web app ip address. Eventually I tried pointing it at 127.0.0.1 11211 and it worked. Why? Because I had a reverse shell i was querying the target application from its server. All I had to do was query the localhost for the memcached server. Im not sure if thats clear but Im trying :)


how to implement TLS between web-server and embedded devices

The design requirements of your system are not fully clear to me. But I will assume in the following that you have full control over the setup and that this setup has only the following requirements:

secure connection between devices and central management server
central management must be able to send commands to devices at any time
IP address for the devices are dynamic and not known to the management server up front, i.e. the device must somehow announce itself to the server initially.

There are several options to implement this, like

Create a VPN between the devices and the management system. This can be done for example with IPSec or OpenVPN and with some variations with SSH too. Within this VPN the devices can have a fixed private IP address thus addressing a device from the server is no problem. And TLS is not needed since the VPN already protects the connections against attackers outside the VPN.
Create a TLS connection from the device to the management system which requires only a certificate on the side of the management system. This TLS connection can then be used with a custom protocol to communicate between server and client. Depending on the setup and restrictions because of firewalls it might be useful to not create a simple TLS connection directly on top of TCP but use secure WebSockets for the bidirectional connection. Still, only a certificate on the server side is needed which is trusted by the client.

These setups are similar in that the secure connection (i.e. VPN tunnel or TLS) is initiated from the client, since the client IP address is dynamic and the management system has a static IP or at least a static hostname. It might be useful to add some authentication of the client to this because you don't want that some attacker connects to your management system.

One way would be to create your own PKI with your own CA and issue a unique certificate for each device. The subject of this certificate can be some device-id which you can use to identify the device. These client side certificates could be used for authentication in the VPN or as client certificates in the TLS connection. And, if a certificate got compromised (i.e. someone hacked the device) you can simply centrally block access with this certificate in your management system.


How Whatsapp shows link previews despite E2E encryption?

WhatsApp client makes http request to the site as the sender types in, in order to fetch site meta properties.
<meta property="og:title" content="Information Security Stack Exchange">
<meta property="og:description" content="Q&A by infosec enthusiasts">
<meta property="og:image" content="https://cdn.sstatic.net/Sites/security/Img/logo.svg?v=f9d04c44487b">
<meta property="og:url" content="https://security.stackexchange.com">

Link preview requires sender to be online and the message is yet to be sent. WhatsApp client makes http request for any text that matches with the regular expression of the URL.
Once metadata is retrieved, it is sent as message. The problem with this design is that if there's a query string in a URL, WhatsApp client will not escape it and put it in a GET request as parameter. This leaks the next immediate word in the typed message if you forget to put space between the URL and text while typing the message.


What is a AUTH-KEY in the security of the computers?

A seed is a non-secret value used as a starting point.  I'm not sure what it's the starting point for, but presumably the algorithm needs a (relatively well-chosen) number to start from.

Based on the Wikipedia article, the key is not known only by the client; the server knows it too.  The HMAC is a method for disguising the shared secret in such a way that anyone who intercepts the communication doesn't learn the shared secret, and thereby gain permanent access to your account (similar to digest authentication).


(Theoretically) intercepting GCHQ's smartphone exploit

First, SMS exploits are not unheard of.  Quite the opposite...Android has recently been beset by the Stagefright exploit and variants that would allow exactly the sort of things described.  So, if in fact this was a real program and not simply wild speculation on Snowden's part, it may in fact have been leveraging Stagefright or something similar, rather than a still unknown zero-day.

As to your specific plan, I see one glaring issue.  Are you familiar with the "Underpants Gnomes" episode of the TV show Southpark?  If not, the episode was about a group of gnomes who stole underpants, and when asked why, it turned out they had a business plan for it.  That plan was this:

Steal underpants
???
Profit.

You see, it's that second step that's the killer, and you have the same problem with your plan.

You have:

Setup a smartphone as a honeypot
Set the phone up in such a way that it would attract the attention of GCHQ causing them to send their specially crafted SMS
Reverse engineer the message sent and then craft a patch

So, how again exactly do you get GCHQ to send you their message?  I don't know, and I doubt you'll find anyone who does, and certainly not with any reliability.  So, while it's a nice theory, and it certainly builds on the honeypot model which does indeed work, the problem is that the specificity of the attack that you need to occur is so incredibly restrictive that it's virtually guaranteed to never happen.  Being struck by lightning begins to look like a refreshingly likely alternative.

So while there's nothing theoretically wrong with the approach, practically, it almost certainly won't work.


Is it legal to store/send user's device's IMEI/MEID?

As this is a legal question, the usual IANAL disclaimer applies.

In the UK, at least, it is completely legal to store the IMEI number of a mobile device. I can't imagine it being any different for Spain, because an IMEI isn't personal data, it's a device serial number. However, you may come under scrutiny if you later have a breach that leaks the IMEI number attached to personal data (e.g. name, address) because that data would allow an attacker to sniff cell traffic and discover that a person is within the cell tower's range.

If you're just implementing a banning system, why not hash the IMEI with a cryptographic hash algorithm such as SHA1? It doesn't need salting, since the keyspace is large enough to prevent dictionary attacks anyway. That way, if a breach does occur, the IMEIs are computationally difficult to discover.


An auditor examines an organization to determine if they appear to be compliant with a particular standard or regulation. They make their findings based on evidence, often directly supplied by the organization upon request of the auditor. And they are generally independent from the organizations they audit.

In the case of a security audit, the auditor may look for evidence that the organization has a security policy, that the policy is adequate to protect them according to the standard, and that the organization follows it. That policy will state practices to be followed, such as requiring code reviews. An auditor likely won't do a code review himself, but he might look for a documentation trail that demonstrates the organization does do code reviews. The standard may also require annual penetration tests, and he will examine documents produced by the penetration testers. He might also check with the pen testing company to be sure the organization wasn't lying about having pen tests. If he doesn't see such documentation trails, he finds that the organization is out of compliance.

An auditor can't verify that an organization is secure. He can only find that an organization appears to be trying to operate in a secure manner.


How to detect malicious files or web shell on a vps web server

Conceptually yes, you can do this. You need to use on an Anti-Virus tool to scan the file system for you, like ClamAV.


Location/proximity based decryption using separate machine

I would say sticking a NFC Smartcard would be the best solution. Then physical presence would be required, and you could even have assymetric encryption, eg encrypting with a public key and then you have to be physically present to decrypt data, and it works in the way you say, eg you ask the card to decrypt something.

The advantage with a NFC Smartcard, is also that it can be embedded into objects (eg cast or mounted inside something), making it significantly more difficult to "steal" the smartcard. Google "NFC OpenPGP" and you will find a few solutions on this.

Another advantage is that no power is required, since the interrogating reader (for example a mobile phone) will provide the required power to card.


Symmetric Key Cryptography vs Public Key Cryptography

Public key cryptography is for when there are several distinct entites, i.e. he who decrypts is not the same person than he who encrypts; similarly, when we want people to be able to verify signatures without granting them the technical power to produce signatures of their own.

Public key cryptography is not inherently "more secure" or "less secure" than symmetric key cryptography; public key cryptography does things that symmetric key cryptography cannot do (the "entity separation"), but it does so at a hefty price (more maths, more code, more complexity, bigger objects, more CPU). Moreover, there are things which symmetric cryptography does much better than public key cryptography, in particular managing bulk data (RSA encryption is good for 100 bytes, not for 100 gigabytes).


Is it safe to commit ascii-armored symmetric private key to VCS?

I would strongly recommend AGAINST it ...

Passphrase on a SSH key isnt meant to protect it indefinitely ... it simply buys you time. If you brute force a password on a program or website it could lock you out after a specific number of tries.  It could also notify the powers that be that someone is attempting to break in.  A SSH Key is simply a file though ... if someone obtains it they can throw rainbow tables at it all day every day for years if they want to and then it is no long and IF they crack it but WHEN.

this picture is outdated, but it gives you an idea of how bad of an idea it is ... the fact that the picture is outdated should give you an even better idea

https://www.grc.com/haystack.htm


Can MDM on an iPhone restrict custom keyboard usage?

Yes! iOS MDM can limit custom keyboard for managed corporate apps.

  Custom Keyboard extensions provide keyboards beyond the ones already
  built into iOS. Managed Open In can prevent unauthorized keyboards from
  appearing in your corporate apps.

  see page 7 of https://www.apple.com/business/docs/resources/Managing_Devices_and_Corporate_Data_on_iOS.pdf


Setting Same-Site cookie attribute to Lax

Is setting Same-Site attribute of a cookie to lax the same as not setting the Same-Site attribute?

In Google Chrome < 76 – no. Setting SameSite=lax is safer than omitting the attribute. (But if your implementation currently relies on cross-origin requests, double-check that adding the attribute doesn't break anything.)
Here are the differences:

When you don't set the SameSite attribute, the cookie is always sent.

With SameSite=lax, the cookie is only sent on same-site requests or  top-level navigation with a safe HTTP method. That is, it will not be sent with cross-domain POST requests or when loading the site in a cross-origin frame, but it will be sent when you navigate to the site via a standard top-level <a href=...> link.

With SameSite=strict (or an invalid value), the cookie is never sent in cross-site requests. Even when clicking a top-level link on a third-party domain to your site, the browser will refuse to send the cookie.

Starting with Chrome 76, your browser has an option to make no SameSite behave like Samesite=Lax. This will be default in Chrome 80. From the feature description:

The Stable version of Chrome 80 is targeted for enabling this feature
by default. The feature will be enabled in the Beta version only,
starting in Chrome 78. This feature is available as of Chrome 76 by
enabling the same-site-by-default-cookies flag.

Also have a look at the RFC draft and Sjoerd's blog post.


Is HTML5 sessionStorage secure for temporarily storing a cryptographic key?

In short; A browser restart. However, not every browser implements the specification defined by the W3C the same way.

  a) Does anyone have any knowledge on how the Tier 1 open source
  browsers (Firefox, Chromium) handle the sessionStorage and whether the
  contents could be written to disk, even temporarily in the case of a
  browser crash?

It makes no mention of saving data that at the time resides in sessionStorage. You will need to research each browsers implementation to know for certain.

Please refer to Mozilla's documentation, there is also a bug/feature request to migrate this functionality to a sqlite database.

  b) Are there any mitigations to prevent any leak of the key to disk in
  a browser crash or restart? Are there any about:config settings that
  could be used to disable session recovery after a browser crash?

While each browser's extension API is going to vary, each should implement some error handling, as well as event triggers in the event of a crash.

For example Google Chrome's documentation uses a crash event trigger that doesn't conform to the W3C Progress Events standard RFC documentation.

  c) Is the safest option to not use sessionStorage at all for storing a
  key? Or perhaps mitigate the risk by using full disk encryption as
  well?

You shouldn't need to store the derived key, once records are decrypted and written to the DOM during a session the key should only need to persist until the session ends when encryption takes place. Use of sessionStorage is good for maintaining data within the DOM only while the tab/browser is open, hence the name 'session'.

With that said if your really in need of safe guards and feel full disk encryption would mitigate the issue, consider the following scenarios:

Access to the boot partition of a full disk encrypted machine would allow modification of the initramfs (linux installtion) allowing for a method of capturing the input supplied
key used for disk encryption.
The transport used to get the web application to the clients browser if not wrapped in an encrypted protocol such as TLS could allow for injection of malicious code able to capture keyboard input. See the BeEF injection toolkit.

I wrote this tool; secStore.js. It does what you are talking about accomplishing. Just make sure you wrap the transport layer with an encrypted tunnel, use security headers to mitigate XSS attempts and you can even query the loaded browser plugins/extensions to prevent malicious exploits using that avenue.

Hope that helps. Anything with security should be layered and it is almost impossible to cover every attack vector which is where monitoring comes in handy.


Combating Networks of Forged OpenPGP Keys on Public Keyservers

This seems like a key from the Evil 32 key set, which rebuilt the OpenPGP web of trust strong set using short key ID collisions to create awareness on how insecure relying on short key IDs is.

  Can the public key server system still be trusted?

Sure it can, you just never should (and should have) trusted arbitrary keys on the key server network without building a trust path. Building short key ID collision just brought "fake key attacks" to a new level, but these have always been possible.

  What can be done to combat this problem, or reverse the damage?

You cannot really do anything about that key. As all keys from the Evil 32 set have been revoked, at least that key should not be considered at all by others.

But of course, such a key set could be created at any time again! The idea behind the OpenPGP key server network does not provide any trust measures and should not be used for anything but exchanging keys. Trust must be established locally. Always distribute fingerprints or at least long key IDs, and educate your peers about the issue as necessary. Exchange certifications on your real key, for example by joining key signing parties, to enable you and others finding proper trust paths to and from your own key.

  However, given that GnuPG and these keys servers rely heavily on short fingerprints, I think this effectively breaks the entire public key server system.

Neither of those rely on short key IDs at all, unless the user makes it to do so. GnuPG has a debatable default of printing short key IDs in overviews, though (which can be changed by using the keyid-format option (from man gpg):

--keyid-format none|short|0xshort|long|0xlong
   Select  how  to  display key IDs.  "none" does not show the key ID at all but
   shows the fingerprint in a separate line.  "short" is the traditional 8-char‐
   acter key ID.  "long" is the more accurate (but less convenient) 16-character
   key ID.  Add an "0x" to either to include an "0x" at the beginning of the key
   ID, as in 0x99242560.  Note that this option is ignored if the option --with-
   colons is used.


Cookie hijacking bypassing authentication?

Usually with web applications, after the user has authenticated, the server will supply a session cookie to the browser, which is supplied with each subsequent request to the application in place of having the user supply their password with each request.

As such, if an attacker is able to steal a user's session cookie and make requests to the server, it is likely that the server will assume the request comes from the original user and provide access to the application, as long as that cookie remains valid.

All of this is speaking generally, in specific cases additional mechanisms might be used to mitigate the risk of cookie theft.


Generally speaking, vulnerabilities are rescored as they become better understood.  It seems that Mitre often scores something in a worst case scenario and then lowers the score as the issue is studied some more.

As to the this particular vulnerability, it's not 100% clear, but the scoring was changed at the same time they made several other changes - one of which was adding the vendor advisory.  That advisory states "The matching server code has never been shipped, but the client code was enabled by default and could be tricked by a malicious server into leaking client memory to the server, including private client user keys."  So, for someone to take advantage of this vulnerability they would have to 1) write the appropriate server code and 2) get a server to use the modified version and 3) get a client to connect to the compromised server.

Now, take a look at a CVSS v3 calculator, for a low attack complexity it says "Specialized access conditions or extenuating circumstances do not exist.  An attacker can expect repeated success against a vulnerable component."  That clearly isn't the case as the attacker must have a compromised server (i.e. a specialized access condition).  Now look at the description for high attack complexity, it says in part "a successful attack ... requires the attacker to invest in some measurable amount of effort in preparation of execution against the vulnerable component before a successful attack can be expected."  Based on the advisory, that certainly seems to be the case.

Disclaimer: I had nothing to do with the scoring of this vulnerability by Mitre (though I do write advisories and score vulnerabilities for my employer), but given the information available, this change makes sense to me.


Confirmed evidence of cyber-warfare using GPS history data

Confirmed cases? Yes, at least two. One is Strava, and the other is Polar.
When Strava updated its global heat map, it showed some areas in supposed desert areas full of activity. Who would go jogging, at night, on the desert? What about US soldiers?

An interactive map posted on the Internet that shows the whereabouts of people who use fitness devices such as Fitbit also reveals highly sensitive information about the locations and activities of soldiers at U.S. military bases, in what appears to be a major security oversight.
In war zones and deserts in countries such as Iraq and Syria, the heat map becomes almost entirely dark — except for scattered pinpricks of activity. Zooming in on those areas brings into focus the locations and outlines of known U.S. military bases, as well as of other unknown and potentially sensitive sites — presumably because American soldiers and other personnel are using fitness trackers as they move around.

Using fitness trackers will allow the enemy to detect the place, extrapolate the number of soldiers, the patrol patterns and path, and even identify the soldiers. If you can identify someone that lives somewhere in Montana, and suddenly spent 4 months on Pakistan, you can bet he is a soldier. And using the pace and heart rate, you can even say how fit the person is.
The Polar leak was even worse:

With two pairs of coordinates dropped over any sensitive government location or facility, it was possible to find the names of personnel who track their fitness activities dating as far back as 2014.
The reporters identified more than 6,400 users believed to be exercising at sensitive locations, including the NSA, the White House, MI6 in London, and the Guantanamo Bay detention center in Cuba, as well as personnel working on foreign military bases.

The Polar API allowed anyone to query any profile, public or private, without any rate limit. The user ID was pretty easy to predict, and 650k+ user profiles were downloaded, several GB of data. Just ask, and Polar would give all.
The post shows lots of sensitive places (nuclear facilities, military bases, NSA headquarters, Guantanamo Bay facilities, among others) and could identify the users on those places, and even their home addresses, Facebook pages and personal pictures.
You don't need to think too much to realize the damage that can be done with all that information.


Understanding processes in "people, process and technology"

A process can refer to any set of policies or procedures you follow. It could be algorithmic, or it could simply be documented policies or procedures that have loopholes or flaws. That is, even if the people involved are doing their jobs to the letter, and the technology is doing what it is expected and supposed to, the process can be abused or exploited.

To give a simple example, say a company has a help desk ticketing system that is used to request permission and privileges. It's a common occurrence for additional information to be needed on the ticket, so users can edit tickets they've created, and you can only create a ticket as a logged in user. The process is as follows:

A user creates a ticket, indicating what codebase or server they need access to.
Someone from the security team checks that the requesting user is supposed to have those permissions, and adds a comment to the ticket or changes the ticket state to indicate it's approved
Someone from the IT department processes the ticket, adding the appropriate permissions.

On paper, that might seem superficially secure, as long as people are doing their jobs (e.g. adding the right user to the right permission set) and the technology/ticketing system are secure.

But what if you come in as a user who is supposed to have permission to edit the help documentation, and after that gets approved in step 2, you edit the ticket to instead say you need permission to access source code that you aren't supposed to have access to, or a production database containing sensitive information, etc? The IT department user in step 3 may look at the ticket, look at the approval, and you now have permissions you aren't actually supposed to have.

What you have is a failure of process, because the official/documented policy doesn't take into account the ability to edit tickets. You might fix the policy by not allowing ticket edits after approval, or by requiring the IT user in Step 3 to look at an edit history of the ticket - but as documented and followed, the process is fundamentally insecure.

To explain how that ties into the blog post you linked - technology and automation could clean up the loophole in the procedure itself. Maybe when security approves it, they directly tie the ticket into the repository that you're supposed to have permission to, and it's forwarded to the IT department as a new ticket, or automated entirely. That removes both one of the human factors for error (IT admin misreading a safe and unedited ticket, or selecting the wrong username), and the process loophole (no verification between steps 2 and 3).


Simple way to secure a webservice used by mobile clients

One way to attack this would be with a replay attack. If I get hold of the message I can re-send it and the server would think that I'm an authenticated user and will grant me access.

This can be solved with server sending a challenge(e.g. one-time token). The challenge needs to be included in some way together with the username and password. Important is that this challenge/token needs to random for the guy with malicious intent to not be able to guess it. An even more simpler solution could be to add the timestamp and have an interval in which the timestamp included in the reply must be within.


Why has MS not enforced a rule/fix for this?

Because it would break existing software. Microsoft published an API where both paths would be searched. Developers implemented software knowing that. To change it would break any software searching in an unquoted directory with a space in the name. "C:\Program Files" means at the very least this is going to be a huge number of services.

Microsoft have to make a risk analysis and here they must have decided breaking legacy software was higher cost than the risk of unquoted search paths.


Why can't WhatsApp read end-to-end encrypted messages?

Whatsapp wasn't a secure application to begin with. But with so many accounts being compromised the company had to do something, so they introduced the over advertised "END TO END ENCRYPTION" Which is a standard maintained by mostly all others. But yes the keys are generated on the client side and even stored in the same place. As the database is stored on the client side rather than on the server it is a bad idea to store the keys with them too.

Yes there is a possibility that the algorithm they used to encrypt the messages may have a back door or a master key that can decrypt any message. check the WhatsApp Legal page read 7. Limitation of Liability, even if they want to read your messages and you somehow get to know about it, they can easy blame it on a 3rd party. And just for a moment lets cross that line where they ensure that they can't and won't read your messages because if they can encrypt these messages and have access to the keys they sure as hell can read them too. If your conversation is controversial or illegal and they can earn profit by exposing that to a right party there are chances that you are being monitored.

The only security which is added according to me is that now if anyone who tries to tamper/capture my message from the network is gonna get an encrypted cipher rather than plain text.


Do password managers leak information with swap memory?

As I've already pointed out in my previous comment, this attack has been foreseen and already countered (by most cryptography using applications).

The way you do this is, you (the developer) tell the operating system (OS) not to swap out this particular section of the memory. The OS will usually honor that and "make a note" somewhere in the memory manager not to swap this out. However even this marked area may get swapped out (if too much data is declared "unswappable" or a kernel-mode program needs "too much" memory) so it's better than doing nothing (and letting it be unswappable) but still not perfect and tells you not to flag everything unswappable.

As you're concerned about swapping out secret data to disk you may also be concerned about the hibernation state many OSs offer, where you actually write the full current RAM to disk so you can boot up faster at a later point and can resume your work. This attack scenario is less commonly considered but should be countered by careful treatment (-> erase all cleartext keys / passwords on hibernation / shutdown) and appropriate data encryption.

As asked in the comments to the other question I'll also quickly provide (some) overview of where to check if the used (open-source) program is vulnerable.

Windows: You need to inspect the memory (password managing) portion of the code and specifically look for VirtualLock() and VirtualUnlock

Unix-like systems: Inspect the same portion of the code as for Windows but now look out for mlock() and munlock(). Also look for mlockall() at any time in the code as this globally locks the memory into RAM.


What kind of ISO 27k certifications can an individual get?

An individual cannot be certified to ISO 27001. It is a management system standard for organisations. An individual could become an ISO 27001 lead auditor or and ISO 27001 lead implementer.


No - the whole connection would either be over HTTP or HTTPS - request and response.

I can't think of a situation where encryption would be required for the request but not for the response - there is no advantage to this since the SSL handshake would have to take place anyway.


What would the high priority steps be for securing a small (cloud) application?

I think your implied criticism of the resources there is a little bit unfair.

But ok, so the premise is I get 30 minutes to secure the Linux server as well as possible?  Fair enough.  Here's a proposed checklist:

Turn on automatic updates for all software.  Choose a distribution that provides security updates for an essentially unlimited time.  (For instance, I wouldn't use Fedora for this purposes, because after 2 releases -- a year or so -- Fedora will no longer provide automatic security updates, which might render my server silently insecure after a certain amount of time.)  Update all software packages.
Enable a software firewall (iptables) and configure it to block inbound access to everything but SSH, VNC, and the port for that one server you are running.
Turn on automatic periodic backups.
Confirm that if the server gets hacked, it's not a big deal, either for my employer or for my professional reputation.
Configure SSH to allow only public key authentication (disable password authentication).
Reboot the Linux server.
Check that you got the firewall configuration right by scanning all open ports on the server using nmap, and making sure that nothing shows up other than the 3 you intended to allow.
Check that you can access your service (i.e., that none of your security lockdowns broke the server application you are running).

P.S. I'll point out that my answer on those threads already comes pretty close to your criteria; and please see my answer in any case for more elaboration on several the suggestions above.

The SANS checklist mentioned there already comes pretty close to your criteria, too, as it seems to be ordered by priority.


Difference between Certificate pinning and public key pinning

It really depends on how your application/site manages the certificates and public keys, i.e. how often are the keys and certificates rotated. For example, if your site rotates the certificates very often, then you'll also need to update your application that often as well, if you are pinning the certificate. Whereas, in this use case, pinning public key will be a better idea since the public key associated with the certificate will remain static.

From the OWASP link that you mentioned in the question:

  Certificate

  The certificate is easiest to pin. You can fetch the certificate out
  of band for the website, have the IT folks email your company
  certificate to you, use openssl s_client to retrieve the certificate
  etc. When the certificate expires, you would update your application.
  Assuming your application has no bugs or security defects, the
  application would be updated every year or two. At runtime, you
  retrieve the website or server's certificate in the callback. Within
  the callback, you compare the retrieved certificate with the
  certificate embedded within the program. If the comparison fails, then
  fail the method or function.

  There is a downside to pinning a certificate. If the site rotates its
  certificate on a regular basis, then your application would need to be
  updated regularly. For example, Google rotates its certificates, so
  you will need to update your application about once a month (if it
  depended on Google services). Even though Google rotates its
  certificates, the underlying public keys (within the certificate)
  remain static.

  Public Key

  Public key pinning is more flexible but a little trickier due to the
  extra steps necessary to extract the public key from a certificate. As
  with a certificate, the program checks the extracted public key with
  its embedded copy of the public key. There are two downsides two
  public key pinning. First, its harder to work with keys (versus
  certificates) since you usually must extract the key from the
  certificate. Extraction is a minor inconvenience in Java and .Net,
  buts its uncomfortable in Cocoa/CocoaTouch and OpenSSL. Second, the
  key is static and may violate key rotation policies.

Regarding the MitM, no, your TLS connection will not be vulnerable to any MitM attack as long as you've implemented the certificate pinning correctly. Even if an attacker is able to get a valid certificate for their own domain with the same public key which your application has pinned (through a rouge CA let's say), they still wont have have the corresponding private key. Thus will not be able to create a valid TLS connection with your application (since they will not be able to perform TLS handshake itself).


Malicious software that only logs keyboard strokes rarely exists in the wild. Most key loggers for graphical interfaces (e.g. Windows) are more sophisticated and log all user interaction including mouse, copy and paste events by hooking into the operating system.

Key loggers are normally a small subset of a rootkit that may also include the ability to act as a man-in-the-middle (MITM) and capture your credentials or session information without logging any key strokes.

The best way to foil key loggers is not to have them.

Ninefingers answer on Methods of mitigating threats from keyloggers has good recommendations. E.g. Monitor network traffic, use an intrusion prevention system (IPS) or intrusion detection system (IDS).

In addition I would add:

Avoid logging into websites/accounts using computers that you don’t have control over. E.g. At work, at a friend or parent’s house.
Avoid installing software that is not from a reputable source. Use digital signatures and file hashes.
Be aware of what applications and services run on your computer. While rootkits do stealth themselves making them hard to detect, knowing what should be running is definitely an advantage.
Use two factor specifically one-time-password (OTP) authentication to websites where possible. In the specific scenario of Internet banking, financial intuitions often offer a token or SMS based service that provides a password or number that can only be used once.
Use protected mode browsing that disabled browser plugins or scripts.
Use low security accounts for normal activities.
Apply security updates.
Change password regularly.

And while this does not prevent key loggers, backup you files regularly. I say this because if you suspect that you have a rootkit then you should wipe your installation and restore only the data you need.


How do hackers search for vulnerabilities on certain ports?

Basically some tools (like nmap) try to open session over each port of a target. If the session is opened, the tool will try to dialog with the port in every way it knows (http, ftp, smtp, mysql, ...) until it finds the good protocol.
For UDP, the first step is omitted as this is a sessionless protocol.
Before trying every protocol, the scanner can often rely on the banner sent by the server after the session is opened (for example something like "welcome to OpenSSH server v2.2, only the corporate users are allowed to login").
Knowing an open port and the associated protocol the hacker can start to look for vulnerabilities.
There are 3 main ways to do that:

recognize a specific version displayed in the banner and look for publicly known vulnerabilities associated with this version (based on the CVE database for example)
active exploitation: try to run exploits (a program written to exploit a vulnerability) against the target and see which ones are succeeding
read or deduce how the service is configured to discover vulnerabilities due to misconfiguration (most of the time, a service displays its configuration, if not, it is possible to deduce if a specific setting is present or not by trying to call the associated function)

If your question was more about how the vulnerabilities are discovered at the first time. It's more by code audits, bug bounties, whitebox testing, reverse engineering, ... in a controlled environment.
Then the discovered vulnerabilities are registered in the CVE database (maintained by the MITRE) and become public vulnerabilities that everyone can know if a host is affected knowing the version it uses.


How can someone upload a PHP file to a server without an upload form?

There are a lot of ways. Judging by the main features of your website, an attacker could have used:

SQL injection: it is not necessary to have direct access to the database. If you want technical details, this question and its answers explain different ways to obtain a shell from a SQL injection;
credential theft: the attacker could have stolen or otherwise obtained your FTP credentials. This can happen through bruteforce attacks, but since standard FTP is not encrypted, and the password is transmitted in cleartext, an attacker could also have sniffed the connection (for example, if you were using a public Wi-Fi network), obtained the password and used it to upload these files;
file inclusion (LFI/RFI):  if the website is not designed in a careful way, an attacker could upload any PHP file even without any form,database, or stolen credential. For more information: https://www.owasp.org/index.php/Testing_for_Local_File_Inclusion and https://www.owasp.org/index.php/Testing_for_Remote_File_Inclusion;
malware in your computer: it is possible for an attacker to infect the computer you use to access the website with malware, which could in turn be used to upload PHP files in the website as if you did it. You should already know that there are several ways to infect your computer with malware, but I'm going to highlight one. Spear phishing;
countless other ways. I strongly suggest you to take a look at https://www.owasp.org . It contains a lot of information about web application security, including how to perform code reviews, how to test your website for common vulnerabilities and how to eventually defend it from most attacks.


Brute force a hard drive when most of the password is known

John the Ripper Jumbo has LUKS format available.  Use luks2john first, and then use JtR normally, walking through the characters one at a time to see which is wrong.


Two message key agreement and mutual authentication protocol?

Triple Diffie-Hellman (3DH) is a simple authenticated key exchange with forward security and deniability.

Client and servers each generate a long term (identity) key pair. For each key exchange they generate an ephemeral key. It uses the same number of messages as ordinary DH.

The client sends both its public keys (identity and ephemeral).
The server verifies the client's identity public key. The server responds with its two keys.
Both sides derive their symmetric keys using three Diffie-Hellman exchanges. (Something like the following.)

X1 = DHE(ClientEphemeral, ServerEphemeral)
X2 = DHE(ClientEphemeral, ServerIdentity)
X3 = DHE(ClientIdentity, ServerEphemeral)
SharedKeyn = KDF(X1 || X2 || X3, n)
The client and server destroy their ephemeral keys.

No dedicated signing algorithm is needed for authentication with 3DH.

Since you mentioned ECDH and because it doesn't sound like you have the specifics of some other  key exchange key scheme worked out, I recommend using 3DH instead. (Use symmetric key encryption and symmetric key authentication, obviously.)


Setting DHCP lease time to very small time increases security?

Depends on the view point, if you're seeing this from the DHCP server impersonating and poisoning attack vector, you are actually decreasing security and the time it takes for the exploit to succeed. You are also increasing the chances of races to succeed on some race condition scenarios. In conclusion, this question is better asked in some specific explicit scenario or attack vector that you're worried about and not as a general rule.


Import a subset of private subkeys in GPG

You're probably dealing with two issues:

GnuPG before version 2.1 cannot merge private keys, and
selecting explicit subkeys to export requires a ! after the key id, for example (given 0xdeadbeef is your subkey ID)

gpg --export-secret-subkeys 0xdeadbeef!

Possible solutions to your problem are:

Use GnuPG 2.1 (then you can merge the exported individual subkeys during import).
Export the required subkeys all at once (given you have one keyring which already contains all subkeys, does not work if these are distributed among multiple keyrings as it would require merging the keys), for example

gpg --export-secret-subkeys 0xdeadbeef! 0x12345678!

Use the gpgsplit command to take apart the OpenPGP message to individual packets, then join them manually in the right order using cat. This is a rather difficult task requiring deeper knowledge of the OpenPGP standard, I'd go for either of the first two solutions.


New Hires get phishing emails very quickly - Reasoning and how to stop

Presumably, your MX record is suffering from a directory harvest attack (DHA). There are lots of ways to do this and unless you're very savvy at pouring through your mail logs, most of them are (by design) hard to detect.
The simplest form of DHA involves SMTP vrfy and expn commands. You can block these entirely. More sophisticated attacks can involve composing emails and then never completing them (the trailing . marking the end of a data command, or even just rset or quit or dropping the connection before issuing a data command).
If you're using o365 exclusively, harvesting from the MX is less likely a concern (I assume Microsoft is savvy enough to block most DHA attempts, though they may not provide enough forensic data to determine if a DHA was attempted or how successful it was before it was cut off). Perhaps attackers have found another source of this data, like a list of your users or a compromised user system or account that attackers can access to read mail or the address book.
If your usernames are predictable, e.g. Firstname.Lastname@company.tld, an attacker can determine users by scraping a company employee listing or a site like LinkedIn. Another source of addresses is public mailing list archives.
One thing you can do is to set up a spam trap (aka a honeypot). Just make a new account for a fictional user and never tell anybody. Wait for a while to see if it starts getting mail and you'll know there was a DHA. If you don't get any bites, then your trap wasn't listed in the place(s) attackers harvest. Try to come up with what those might be and spin up new dedicated addresses (or, if you have to pay per account, add new seeding techniques to the single trap account one by one, with a few weeks between each addition so you can identify it).


Great question!  As it happens, I can present experimental data on this question -- and the data is fascinating.  (I noticed that some of the answers contain speculation from first principles about how much security these security images offer.  However, the data turns out to have some surprises for all of us!)

Experimental methodology.
"Security images" have been evaluated in a user study, conducted with ordinary users who were asked to perform online banking in the lab.  Unbeknownst to them, some of them were 'attacked' in a controlled way, to see whether they would behave securely or not and whether the security images helped or not.

The researchers evaluated two attacks:

MITM attack: The researchers simulated a man-in-the-middle attack that strips off SSL.  The only visible indication of the attack is that lack of a HTTPS indicator (no HTTPS in the address bar, no lock icon, etc.).
Security image attack: The researchers simulated a phishing attack.  In this attack, it looks like the users are interacting with the real bank site, except that the security image is missing.  In its place, the attack places the following text:

  SiteKey Maintanance Notice:
  Bank of America is currently upgrading our award winning SiteKey feature. Please contact customer service if your SiteKey does not reappear within the next 24 hours.

I find this a brilliant attack.  Rather than trying to figure out what security image to show to the user, don't show any security image at all, and just try to persuade the user that it's OK that there is no security image.  Don't try to defeat the security system where it is strongest; just bypass the entire thing by undermining its foundation.

Anyway, the researchers then proceeded to observe how users behaved when they were attacked in these ways (without their knowledge).

Experimental results.
The results?  The attacks were incredibly successful.

Not a single user avoided the MITM attack; every single one who was exposed to the MITM attack fell for it.  (No one noticed that they were under attack.)
97% of those exposed to the security image attack fell for it.  Only 3% (2 out of 60 participants) behaved securely and refused to log in when hit with this attack.

Conclusions.
Let me attempt to draw some lessons from this experiment.

First, security images are ineffective.  They are readily defeated by very simple attack techniques.
Second, when assessing what security mechanisms will be effective, our intuitions are not reliable.  Even expert security professionals can draw the wrong conclusions.  For instance, look at this thread, where some folks have taken the view that security images add some security because they force the attacker to work harder and implement a MITM attack.  From this experiment, we can see that this argument does not hold water.  Indeed, a very simple attack (clone the website and replace the security image with a notice saying the security image feature is currently down for maintenance) is extremely successful in practice.

So, when the security of a system depends upon how users will behave, it is important to conduct rigorous experiments to evaluate how ordinary users will actually behave in real life.  Our intuitions and "from-first-principles" analyses are not a substitute for data.
Third, ordinary users don't behave in the way security folks sometimes wish they would.  Sometimes we talk about a protocol as "the user will do such-and-such, then the server will do thus-and-such, and if the user detects any deviation, the user will know he is under attack".  But that's not how users think.  Users don't have the suspicious mindset that security folks have, and security is not at the forefront of their mind.  If something isn't quite right, a security expert might suspect she is under attack -- but that's usually not the first reaction of an ordinary user.  Ordinary users are so used to the fact that web sites are flaky that their first reaction, upon seeing something odd or unusual, is often to shrug it off and assume that the Internet (or the web site) isn't quite working right at the moment.  So, if your security mechanism relies upon users to become suspicious if certain cues are absent, it's probably on shaky grounds.
Fourth, it's not realistic to expect users to notice the absence of a security indicator, like a SSL lock icon.  I'm sure we've all played "Simon Says" as a kid.  The fun of the game is entirely that -- even when you know to look out for it -- it is easy to overlook the absence of the "Simon Says" cue.  Now think about a SSL icon.  Looking for the SSL icon is not the user's primary task, when performing online banking; instead, users typically just want to pay their bills and get the chore done so they can move on to something more useful.  How much easier it is to fail to notice its absence, in those circumstances!

By the way, you might wonder how the banking industry has responded to these findings.  After all, they emphasize their security images feature (under various marketing names) to users; so how have they reacted to the discovery that the security image feature is all but useless in practice?  Answer: they haven't.  They still use security images.  And if you ask them about their response, a typical response has been something of the form "well, our users really like and appreciate the security images".  This tells you something: it tells you that the security images are largely a form of security theater.  They exist to make users feel good about the process, more than to actually protect against serious attacks.

References. For more details of the experiment I summarized above, read the following research paper:

The Emperor's New Security Indicators.  Stuart E. Schechter, Rachna Dhamija, Andy Ozment, and Ian Fischer.  IEEE Security & Privacy 2007.  (edit: updated link)


Do software companies intentionally upload fake/infected versions of their own software to file sharing networks as a means to combat piracy?

I would suspect that intentionally causing harm to other peoples' computers is illegal in most parts of the world. I also believe that in most parts of the world someone committing a crime against you (or in this case just having the intention to do so) does not necessarily give you the right to commit a crime against them. But as with most people on this website, my area of expertise is technology, not law. So I would refer you to the people on law stackexchange which might explain this far better than we could.

No, these malware-infested pirated copies are usually spread by criminals who have no affiliation with the game companies and are looking for an easy way to grow their botnets.

Regarding low-quality versions which malfunction after a while: There is a huge competition between piracy groups to be the first to release a certain game. That means they often do not take time to test the game properly to make sure that all copy protection features are disabled properly and without breaking anything. Also, games are sometimes leaked and pirated before the actual release (a common source are press pre-release copies), so various last-minute patches and bugfixes might not be applied yet which do exist in the actual release version.

But I know of one case where a company openly admitted to uploading a modified version of their game to piracy websites. However, their modifications were not malicious. They just made the game unplayable in a quite original way:

  When we released our very first game, Game Dev Tycoon (for Mac, Windows and Linux) yesterday, we did something unusual and as far as I know unique. We released a cracked version of the game ourselves, minutes after opening our Store. [...]
  The cracked version is nearly identical to the real thing except for one detail… [...] as players spend a few hours playing and growing their own game dev company, they will start to see the following message, styled like any other in-game message

    Boss, it seems that while many players play our new game, they steal it by downloading a cracked version rather than buying it legally.
    If players don’t buy the games they like, we will sooner or later go bankrupt.

  Slowly their in-game funds dwindle, and new games they create have a high chance to be pirated until their virtual game development company goes bankrupt.

And then they amused themselves about the software pirates who posted on the official support forum complaining that the software piracy game mechanic is completely overpowered and that there should be a way to take legal actions against the software pirates or develop DRM technology to stop them.


For bcrypt why is JTR so much faster than hashcat?

Most likely explanation: which implementation takes advantage of CPU-specific instruction optimizations.

For john, See john -list=build-info for which Build/SIMD options are enabled.
For hashcat, I'm not sure if there's a way to show which CPU instructions are used for a given algorithm, other than looking at the source code and the compiler output.


Security of external harware when using VMs

Think of a hardware based host as a fisk tank. Immagine that the virtual host is a smaller fish tank that sits inside the larger fish tank. You can add fish to your fish tank: either to the larger tank or the smaller tank. Generally the VM (smaller tank) is created in such a way that software running on the VM can't break free of the VM and run on the real hardware. Metaphorically, you don't let fish swim from the smaller tank into the bigger tank.

A VM comes with a set of virtual hardware: CPU, RAM, graphics chip or board, even BIOS and chipset. These pieces of virtual hardware are software programs running on the real hardware and providing service to the VM. Real USB devices are first plugged into real hardware. From there they can either be shared with a VM or dedicated either to the real machine or the virtual machine.

You can of course isolate a VM from any USB devices, but that would not necessarily protect them VM. The VM is vulnerable to software running on the real machine, because the VM depends on the real machine for it's CPU cycles, memory, and storage. If you plug a Bad USB device into your real machine, it could attack the VM by chnaging the contents of the VM memory or storage without accessing the VM through the virtual USB hardware interface.

There is no conflict here, because VMs are only ment to contain software running on the VM from gaining access to the resource of the real machine.


TCP Peer unexpectedly shrunk window messages in dmesg log

This normally occurs when a client decides to reduce its TCP window size, without the server expecting it. This can be the case when fragmentation is an issue, or when the client is using an embedded device with very little NIC buffer memory. This is a completely normal behaviour, and you're likely to see quite a few such packets in your log. The messages are informational only, and are used to debug networking issues.

I'd be worried if you saw hundreds of thousands of these packets, since there are attacks that involve packet fragmentation and small window sizes, but otherwise it's just the normal sort of noise you should expect to see on any internet-facing network. In fact, the "repaired" part of your message is showing that your network driver fixed the issue, which is usually done by concatenating the payloads of two fragmented packets together. Shouldn't be an issue at all.


Vulnerabilities of having one path of app accessible only via HTTPS but others via HTTP?

Theoretically, the Same Origin Policy, and the HttpOnly and Secure attributes, induce the same general model, which is that your HTTP site and your HTTPS site will be seen by the browser as two distinct animals, thus   cleanly separated. In practice, this is not entirely true; for instance, while the cookies from the HTTPS site will have the "secure" flag and will not be sent to the HTTP site, the converse is not true. An active attacker, by manipulating data as it flows between the client and the HTTP site, could inject a cookie which will be sent to the HTTPS site.

Usually, it is safer and simpler to go full-HTTPS. It is safer mostly in the following sense: it allows you to educate your users into expecting an end-to-end HTTPS site, with the padlock icon. This makes the users less vulnerable. But these users also connect to your site and use its features, so a vulnerable user is also a problem for you.