Plugins to increase security of Chrome? What plugins are there for Chrome, that would increase security while browsing the web?

For Firefox I have used NoScript, Flashblock, and AdBlock Plus, are there equivalents to these plugins for Chrome?

Several plugins I have heard about are uMatrix and uBlock.

Thank you very much.

I am not sure this is the place for this question. Maybe refer to SuperUser but...

I use uBlock Origin. It is a highly customizable tool for ad blocking, malicious site blocking and much more. It allows black listing and white listing of domains and uses public lists of malicious domains to block.


DNS Spoof saves IP to Domain Name after attack is finished, Is there a way to stop this? As I understand after a Domain Name is resolved to a specefic IP through DNS www.example.com resolves to 10.10.10.10, this cache is saved in RAM in a computer for a little bit, AKA five or so minutes. (Note: Correct me if I'm wrong)

So, when I DNS spoof a computer to resolve www.whatevs.com to the IP of my website clone running on my local apache server: 192.168.1.5 . Then it does what it does and it is finished. But, the problem is after the attack is finished and I stop DNSSpoofing, the computer saves www.whatevs.com to 192.168.1.5 for a little while after, before it runs a DNS resolution lookup again to resolve the real IP. Does anyone know how to stop this by making the computer lose the cache, or forget www.whatevs.com's fake IP address, so it must re-resolve it? Thanks!

DNS TTL is used to decide how long we want the entry to be cached on the local machine. Advertise smaller TTL (DNS server/Responder does this) so that the entry will be flushed at the configured time :-)

Try it out. Its fun.

Good luck.


Is there any public information on audited Java open source projects? I'm sure that there must have been any number of audits on common Java open source projects, many of them for governments or publicly-funded bodies.

Have any of the results been made public, so that an average user could take a particular version of a particular JAR (with a particular checksum) and have a much higher level of confidence that it does not contain any backdoors or similar?

A code audit should only be considered a point in time audit, and should be not be considered a future guarantee. It is possible that some product has had an audit or review done by a third party and they may make that report available, but new techniques or different methods, timelines, and budgets could result in additional bugs being found later. In the end, they may not have found anything.

For legal reasons, you are unlikely to find anyone giving a guarantee, warranty, or otherwise on a code review. More useful would be a review of the development process for testing, controls, procedures, and ongoing reviews.

What you may be able to find is documentation of existing vulnerabilities and patches you can apply, reviews, discussions, etc. If you can verify the checksum/hash of a JAR obtained with the one provided form the developer this can give you some confidence. If it's a popular Open Source project, likely people would complain or post patches if a weakness or vulnerability is found. You may also gain some assurance from a signed-JAR. Would you sign something that you put a backdoor in as the original developer?

Also, very few open source licenses give any warranty and may not even guarantee any suitability. You need to take a calculated risk on the author of the code, the service providing the source or executable, and the requirements of the application. You should also have some reasonable assurance in your own environment's firewalls, AV, etc. to block or identify threats.

Lastly, most reviews are likely to be triggered from customization of open code, not from the base package.


E-mail tracking countermeasures I've started using Sidekick to know when an email is opened or one of the links in it is clicked. What I ask now is how to know if an email I received is provided with a similar tracking system.

With Sidekick, every link is changed (to something like www.sidekick.com/abcdefg123), so that's the easy point. The difficult (to me) one is the tracking one. What is more, is it possible to know an email is being tracked before you open it?

You can't necessarily know if an email you receive is designed to be tracked but as tracking is limited to certain techniques, you can infer a higher probability of this behaviour if the email seems tailored towards such an end:

Email includes images that need to be downloaded remotely

Typically an email can have all images and formatting stored internally inside a multipart mime type container. So if an email doesn't do this and refers to external images that your email client must download then this might be an email with a web bug in it.

A web bug is any remote resource that the email client is encouraged to download for displaying the email; such that downloading it proves that the email was opened by the recipient. These can be 1x1 transparent GIFs that have a unique URL, such as http://spy.server/email-1234567890abcdefg.gif

Good desktop email clients will not download external images automatically without your permission to avoid this privacy risk. Webmail services may not provide this feature.

Email lacks some or all of its pertinent information, requiring online access

This isn't necessarily a bad thing, as banks will require you to login to their website to discourage phishing. But any hyperlink in an email can be used to track you if you click on it.

You may not know that an email is being tracked before you open the email unless your email client has fancy anti-malware features. The simplest approach is to set your email client to only render emails as plaintext. This gives you the opportunity to decide if the email looks legit and whether you trust the sender sufficiently to switch to HTML rendering on an as-needed basis.


When and how will Internet Explorer refuse sha-1 certificates? sha1 certificates are deprecated. The web browser Google Chrome shows a red security warning for the website https://sha1-2017.badssl.com/ (sha1 certificate expires in 2017). It shows neutral (neither green padlock nor red warning) for https://sha1-2016.badssl.com/ . Otherwise the pages load normally.

I read http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx but don't understand Microsoft's policy. Will Internet Explorer eventually refuse these certificates too? When exactly, and how so—what will it look like? An address bar warning like Chrome, or a scary interstitial ?

The two websites load without warnings in Firefox 41, but I understand Mozilla plan to introduce "This Connection is Untrusted" interstitials from Firefox 43. https://blog.mozilla.org/security/2015/10/20/continuing-to-phase-out-sha-1-certificates/

Microsoft announced a SHA-1 notice for their browsers starting in June 2016. The wording of the notice is still "under consideration".

  December, 2015 update: Microsoft is aware of recent advances in
  attacks on the SHA-1 algorithm   and we are evaluating the impact of
  moving the dates on our schedule up further to help protect customers.
  The most significant revision we are considering is to introduce a
  "speed bump" into the process in June of 2016, which will provide a
  notice to customers that the website is using a SHA-1 certificate. The
  exact wording of this prompt is still under consideration.

blog entry by Kyle Pflug, Program Manager Microsoft Edge

TechNet article on Windows Enforcement of Authenticode Code Signing and Timestamping


Can I place a private key on a sim card? After google searching about this idea and yielding very little in results I've come to resort to stack exchange:

Is it possible to place a private key on a sim card?
Is it possible for a smart phone app on Android to use the private key for cryptography?  What about iOS?  What about Windows based phones?
If (1) and (2) are feasible, why isn't this capability more prevalent in the Android/iOS/Windows?

It would seem that if (1) and (2) were feasible, then it would make so much sense to utilize the capability, and essentially enact cell phone carriers as certificate authorities (CA) (or agencies of CAs).

In answer to (3)- It was not until recently that API's to do this were readily available without having some significant resources behind you.

Here is a guide to doing what you describe in (1) and (2). http://nelenkov.blogspot.com/2013/09/using-sim-card-as-secure-element.html

There are some applications doing this- the article comments say a bitcoin app is doing exactly as you describe.


Is the date that a password was last changed useful to an attacker? Obviously I want my application's users to change their passwords on some semi-regular basis (in fact a few of our apps must be UL-approved, and they require a system to enforce changing passwords every 90 days). The simplest way to do that is to store the last time the user changed their password on their record. I am also implementing a flag that, if set, basically marks their password as "temporary", forcing the user to change their password on their next successful login.

The question is simple: does storing this data in plain text (the flag and/or the date) expose a vulnerability?

I see one main attack vector, and it's rather serious; an attacker who gained edit rights to the user table could modify the date field or flag, forcing the user to change their password at will, possibly exposing it to a keylogger installed on the client machine. That does require multiple "ins", but if they get in one way they can get in other ways. Read-only information could still provide a similar vector by identifying the next user that must change their password, making them the next target for sniffing their new password.

I do have a system for password-based user data encryption already in place that obfuscates other sensitive data in the system; The question (which I may well have answered myself) is whether to include these fields in the encrypted blob. If I do so, it makes legitimately forcing users to change their passwords more difficult (I might want to force every user to change their password, and some other data to boot, if I were to discover the DB had been dumped), but also prevents an attacker doing the same.

Case for plain-text:

The attacker could change all the dates for one time and repeat.  Not a security vulnerability, but it could annoy the client to no end before it was discovered.
Your attacker could increase the number of password resets, therefore gaining more data to use in an attack.
If a dictionary attack is used the attacker knows to reset his
dictionary attack.
Increasing the date would give the attacker more time for whatever attack he/she chooses and will violate your security planning
Since the majority of users generally change only one number or letter in their password this could open up an attack given some encryption schemes.  If the attacker knows when to check the cypher text it would be easier to build a dictionary of past passwords.
If you are using grouped fields (you mentioned blobs) and list the date it changed the attacker knows the exact difference between the two cypher texts.

Case for encrypted text:

Based on the encryption scheme a history of the cypher texts could expose some knowledge of the plain text.  If the attacker has figured out that your are using dates in your blob (possible since they aren't listed elsewhere) then he/she has a very limited key-space of plain text for that part of the blob.  This could open up some vulnerabilities.

I don't know if any of this is practical.  I am basing this on a 6 week course on cryptography at coursera, but it my two cents.


Is telegram SMS login secure? TL;DR: Can:

A random hacker access my telegram account by entering my phone number on the official web.telegram.org authentication portal and hijacking the SMS code they send? or

A "telegram engineer" access my telegram account by changing a bit the system such that the SMS code is not sent over the GSM network but to his device?

Full question:
I am concerned about a very specific part of the telegram security protocol. I have read a lot of criticism about the protocol itself, but no answer to my question yet. I also know about the telegram security contests, but I know that they are bullshit because they will only tell telegram secure against KPA attacks.
Furthermore, I am not asking about secret chats, I know they are end-to-end encrypted.
I'm asking about the content of cloud-based chats, which is kept on telegram servers. The only article I have found about the topic is this one. It states:

Since without E2EE Cloud Chat data is theoretically accessible, we use a unique distributed infrastructure to protect it. Cloud Chat data is stored in multiple data centers around the globe that are controlled by different legal entities spread across different jurisdictions. The relevant decryption keys are split into parts and are never kept in the same place as the data they protect. As a result, local intruders or engineers can't access this data, and several court orders from different jurisdictions are required to force us to give up any of it.

Thanks to this structure, we can ensure that no single government or block of like-minded countries can intrude on people's privacy and freedom of expression. Telegram can be forced to give up data only if an issue is grave and universal enough to pass the scrutiny of several different legal systems around the world.

As a result, we have disclosed 0 bytes of user data to third parties, including governments, to this day.

I suppose that when I want to access my telegram account from a new device and an authentication token is sent to my other telegram device, this authentication mode is secure, not just in the sense that it cannot be seen by hackers. In fact, I can easily imagine a scenario where the telegram server generates a token that is sent to my device, and the telegram app on my device computes the 6-digit code using both the token and my very private key. In this way, a telegram employee can not access my account even if they know the token generated on the server. (I hope I made it clear on this point, I am not so sure.)
But, continuing the quote from the linked article:

If you are concerned about security in general, there are other important precautions you could take. Consider protecting your account by enabling 2-Step Verification and setting up a strong passcode to lock your app, then it won’t be possible to access your chats by stealing your device or even by intercepting your SMS code. You will find both options in ‘Settings’ under ‘Privacy and Security,’ ask me if you’d like more details.

Does that mean that if someone put my number into web.telegram.org and then intercept the SMS code they can just use it to log in to my account, pretending they are me?
I know that the SMS token only works with the keys generated by the device on which I am trying to access, but another possible attack scenario can be the following: a "telegram engineer" (I am not sure about how telegram employees are organized or structured) modifies the infrastructure a bit such that when a login is required, the token is not sent to me via SMS, but saved somewhere or such that it is sent to their device.
Then they can enter my phone number in the official web.telegram.org web portal and log in as me.
Note that in these attacks it is not required to break any jurisdictions nor to access any encrypted database, just to use the existent official web login portal.

A "telegram engineer" access my telegram account

Short answer is that it's possible.

The simplest way would be for a telegram engineer to change the Telegram client to forward your password when it's entered. Then, Telegram can have bullet proof crypto, you can own the keys, their systems can be audited but the end-to-end system is under the control of Telegram: it's perfectly possibly for them to have a back door.  It's perfectly possible for them to introduce a back door. They probably don't but, they could. If they change the client to capture and forward your password then it does not matter what crypto they use on the back end or in which jurisdictions they store the shards or if they also choose to send you an SMS code because your password is known.


Where can I find a list of un-patched CVEs for a specific piece of software? Is there a database of vulnerabilities somewhere, that can be queried in such a way as to return results for all non-patched vulnerabilities for a specific piece of software?

For example, I would like to see a list of the current non-patched (workarounds don't count as patches) vulnerabilities, including CVE numbers, in Windows 7.

one good starting point for this would be www.secunia.com.  You can get a list by product there, of known security issues, and the note on the page unpatched issues.  For windows 7 for example, there's this list


Can someone trace me from mobile phone IP? I have mobile phone, on which I am using internet. My phone number is registered under name of my employer, because they give you services like cheaper call fares, etc.

I also purchase internet balance using balance I get from my employer on phone.

Now I am interested is it possible my employer or mobile phone service provider relate my identity and browsing history?

There can be two cases while you're browsing :

Over HTTP :

In this case all your traffic goes in plain-text format, hence if an ISP wants to keep track of browsing history, they can easily do that. But in most cases, ISPs doesn't care(unless Government force them to) about what you do with your internet package. But they surely can track you including the things you send to the sites, like passwords, files. And also can impersonate to be one of the sites you want to visit.
Over HTTPS:

Now when you visit the sites over HTTPS protocol, things get tricky for the ISPs and Government Agencies. Since HTTPS does the two important things :

Verify the source : the data being received is from the Original Source.
Protect the data : the data being transferred is encrypted, so that only sender and receiver knows what is going on. This includes the URL of the website.

Since the connection is encrypted with at least 128-bit key. The ISPs can't see what you're browsing or what you're sending to those sites.

But there is a catch, even though the data is encrypted it at-least needs a source and destination. Now the ISPs can see(if they want+care) the IP addresses you are visiting, and by IP address one can roughly estimate the site you're trying to visit.

So, in order to keep the ISPs completely in dark, you need to use VPN while you're doing any online activity. In your case, you'll either need L2TP/IPSec4 VPN service, or use VPNGate with OpenVPN App(Android, iOS).


Is stealing the HTTP Basic Authenication header possible via CSRF? Recently I've been trying to find a way to steal HTTP Basic Authentication credentials via CSRF. For example, if a site is using basic authentication is it possible for an attacker to grab the Authorization header with some sort of proxy hidden in an iframe, or steal it any other way?

I've done some research and nothing I can find really proves this is logically possible.

If anyone has a solid answer, whether this is 100% impossible or actually possible, thanks in advance!

CSRF is a write-only read-none action. Because of the Same Origin Policy the attacker can make a request happen, but he can neither read the details of the request nor read the response. This unreadable parts of the request include cookies (incl. session cookies) and also the information for Basic Authentication.


To prove facebook end-to-end security Is it possible to prove that Facebook Messenger's end-to-end feature is actually device-device encryption and not device-facebook-device Facebook being the man in the middle?

There's no way to prove that unless you inspect every line of relevant source code involved. If you do have access to every line of code, then yes, you can prove to your satisfaction that you're dealing with end-to-end encryption.

However, since the code can be changed at will by Facebook, you'll have no way of knowing whether communication remains secure after your code inspection, or whether it was secure before you inspected the code.

So, unfortunately, the answer is that just like with much of the rest of our lives, you'll have to put some trust in what other people - Facebook, in this instance - tell you. You'll have to decide whether you want to invest that trust, or not.

Network monitoring

Your idea of monitoring network traffic gives you an indicator, but is by no means conclusive.

If Facebook wanted to secretly eavesdrop on your conversation, it wouldn't have to route the messenger protocol through it's own servers. The messenger could just record what you type and use a covert channel to send it to some harmless-looking server later on. The channel used to exfiltrate your messages could be fairly easy to detect (direct connection to the Facebook servers - but since it would be encrypted, you wouldn't know it was part of some other function of the messenger), something like fake DNS queries to a bogus DNS server, or any other harmless-looking form of network connection. If it was time-delayed, the chance that you'd catch it would be basically nil.

Also, even if the messenger DOES route traffic through it's own servers, this isn't a sign of wrong-doing at all. If you want messages to be held while the recipient is out of reach, and have them delivered once he comes online again, you must store them somewhere. End-to-end encryption doesn't mean the messages aren't stored somewhere; it just means that the messages can only be read by the originator and the recipient. So the messenger could do something very simple: It could encrypt every message twice: Once for the recipient, and once for Facebook. Then it would send both messages to Facebook servers, packaged to look like a single message, and you'd never know the difference.

So do they spy on you?

Note that I'm NOT saying Facebook is lying to you; in fact I believe they take end-to-end encryption seriously. If you don't believe in the inherent honesty of people or in Facebook's adherence to law, you might be more convinced by thinking about the public relations disaster that exposure would mean, and that Facebook, being locked in a fight for users with competitors, might not want to risk a significant percentage of users over something that offers them so little advantages. Because if you think about it, what would Facebook gain, exactly, from reading your messages? They already get something very valuable from your usage of Messenger: They know who you're communicating with, and they know how often, and when. This metadata might actually be more valuable that the content of the messages.


Are there any known cases where antivirus software has deliberately ignored malware? Are there any known cases where antivirus companies for some reason have choosen to make their product allow/ignore malicious software?
The reason could be government coercion or former trustworthy companies/developers turning to cyber-crime.

I think the best and most common example of this is software that has malware (specifically spyware/adware) like practices but operates as a "legitimate" business (particularly if they can get this into some terms and conditions and/or rely on users not selecting options correctly or other dark-patterns e.g. "Tick here to confirm you don't want to not install MySearchWebPartner" etc).

For instance there are thousands of posts from irritated people about OpenCandy / ConduitSearch but while some AV engines have now started warning about it, few will actually flag it as malicious.

A lot of the AV companies won't go near them because they are worried about being sued by these companies for loss of revenue if they start blocking them.

I can't find the link right now, but I remember that was the reason Microsoft stated they weren't willing to outright block some software from software silently changing the default search provider or home screen to known nuisance ones for fear of litigation; so they researched providing a warning instead for us to be "better informed".

  Microsoft security products consider adware something that the user should be informed about, and given the choice of whether to remove

http://blogs.technet.com/b/mmpc/archive/2013/06/20/ad-injection-and-you-how-adware-gets-on-your-computer.aspx

See also : http://www.dslreports.com/shownews/58853


Facebook API : App Secret - possible misuse I've recently find out that by simple quick look into compiled code of one of our applications, you can get both App ID (API Key) and App Secret for Facebook API

I suppose that we should really keep App Secret (obviously from the word secret), so that nobody can access it, but what is the main threat related to leak of these items?

If the evil guy obtains these entries, what is the worst possible misuse he could perform?

You are correct. App secret should be secret and should not be easily obtained by reverse engineering your client code.
Facebook uses OAuth so everything I say here also applies to all the applications that use OAuth to authorize and authenticate. The app secret authenticates your client to facebook. Just like a username/password authenticates a user to a webservice, mobile/desktop clients use app secret key as a credential for server to validate that its the 'real' legitimate client app.

  If the evil guy obtains these entries, what is the worst possible misuse he could perform?

He could make a spoofed client that looks just like your client/application and release it. Unsuspecting users will download it and use it to connect to facebook. The fake app doesn't still get users credentials (which is good) because the authentication of user credentials happens on a facebook page. However, the user ends up authorizing this fake app on facebook. Facebook happily does that because it believes that anyone who presents that secret is you. As a result, the fake app gets the 'access token' for the user and can start posting comments and do other things that your real app doesn't intend to do.
So in a nutshell, its your reputational value that is at stake here. Other clients can impersonate as your client to facebook.

This is a thorough case study of one such twitter client which stored consumer key (their equivalent of app secret) in plain text.

I am quoting one line from that blog:

  It’s very important to understand that a compromised consumer secret key doesn’t jeopardize the security of the users of the application. The key can’t be used to gain access to the accounts of other users, because accessing an individual account requires an access token that individual instances of the client application obtain automatically on behalf of the user during the authorization process.

Now, how do you protect the client secret?
If it is a standalone client (like a mobile app), you have little choice but to embed it in some form. Unfortunately for a expert reverse engineer, its only a matter of time before it can be decoded. After all its somewhere there (in some form) in the client. If the client can re-calculate/re-assemble it, so can a reverser.

Edit: If your application architecture permits it, your server can perform the OAuth steps on behalf of the client/mobile app. This way the key resides in the server, it does all the OAuth steps and passes the access_token to your client to use it to access user's facebook data. At this point you are doing something very similar to the browser - web server - facebook interaction described here. Just replace 'User's Browser' with your 'Client/Mobile App' and 'Your App' with 'Your Server' in that picture.

If this is some sort of a web application, this can be easily achieved by keep the key only on the server side and using facebook's server side flow to prevent app secret from leaking out.


Does X.509 standard claim to check client certificate's expiration date on server side? Does the X.509 standard claim to check client certificate's expiration date on server side?

Consider an expired client certificate in the trust store of web server. If some client tries to authenticate with an expired certificate, should the server (with trust manager algorithm X.509) reject such authentication and certificate?

Please, in your answers, provide links and sections numbers on official documentation (RFC).

I don't think there is a specific standard dealing with client certificates. There is a general mechanism for certificate validation (RFC 5280) and the whole system of CRL assumes that certificates have a limited lifetime, because the CRL is only used for certificates which are not yet expired.

But note that the whole process of validating the trust chain and lifetime is only relevant if validation is done based on a PKI. If the server simply trusts a specific certificate or public key and the client sends exactly this certificate than the server might ignore any additional validations.


How to install Metasploit on Mavericks + MacPorts? I would like to install Metasploit on an hardened OS.
For this purpose I chose Mavericks
just because I'm able to harden this OS pretty far.

I would like to install Metasploit with MacPorts because until now, all the best security tools I needed were correctly manageable with MacPorts through 4 different versions of MacOS X (Snow Leopard, Lion, Mountain Lion, Mavericks).
(This installation challenge is part of a baptism by fire.)

I already did this installation on previous versions of this OS.
I also already found pretty good references to install Metasploit on MacOS X:

Install the Metasploit Framework on Apple Mac OS X
Guide to Installing Metasploit 4 and Armitage on Mac OSX Lion
How To Install Metasploit Framework In MacOSX

Unfortunately none of these answer to my search, and none lead me to a successfull installation.

Do you know a correct and tested receipe to install Metasploit on Mavericks + MacPorts?

Version used

MacOS X        10.9.4
Xcode          5.1.1
MacPorts       2.3.1
Ruby           1.9.3
Postgresql     9.3.5
Metasploit     4.9.3

Method

To avoid any confusion between system, MacPorts and Metasploit binaries
it is fundamental to start to install everything in clearly separate
part of the filesystem.

Here are the choices I took:

/local/MacPorts     initial install of MacPorts
/local/Metasploit   install of Metasploit
/opt/local          install of everything managed with MacPorts

Steps

The overall steps to install completly Metasploit are:

Xcode + command line tools
MacPorts
Ruby
Postgresql
Metasploit

1. Xcode + command line tools

Download Xcode 5.1.1 from the App Store (2 Go)
launch it to check and accept the licence
install the command line tools with:

xcode-select --install

2. MacPorts

Create the initial directory structure (let's say my account is BOB).

$ /usr/bin/sudo mkdir -p /local/MacPorts
$ /usr/bin/sudo chown BOB /local/MacPorts

Download the latest tarball:

From MacPorts:
MacPorts 2.3.1
to save it under:

/local/MacPorts/MacPorts-2.3.1.tar.bz2

Extract

$ cd /local/MacPorts
$ tar xvf MacPorts-2.3.1.tar.bz2

Configure, install

$ /usr/bin/sudo mkdir -p /opt/local
$ cd MacPorts-2.3.1
$ ./configure --prefix=/opt/local
$ /usr/bin/sudo make install

port isn't in my PATH, and this is normal.
1st PATH switch

(I'm using zsh) insert within ${HOME}/.profile, within the section
which is always run and after any other PATH or MANPATH definition:

PATH=/opt/local/bin:/opt/local/sbin:${PATH}
export PATH
MANPATH=/opt/local/share/man:/usr/share/man
export MANPATH

PATH switch:

$ . ${HOME}/.profile

Update MacPorts DB

$ /usr/bin/sudo port -d selfupdate

port in in my PATH, and this is normal.

3. Ruby

Download, configure and install ruby19

$ /usr/bin/sudo port install ruby19
$ /usr/bin/sudo port select ruby ruby19

check that everything is ok thus far:
    $ type ruby
    /opt/local/bin/ruby
    $ ruby --version
    ruby 1.9.3p547 ...
Download, configure and install bundler

$ gem install bundler

4. Postgresql

Download, configure and install postgresql93

$ /usr/bin/sudo port install postgresql93-server

the correct install will display:

To create a database instance, after install do
 sudo mkdir -p /opt/local/var/db/postgresql93/defaultdb
 sudo chown postgres:postgres /opt/local/var/db/postgresql93/defaultdb
 sudo su postgres -c '/opt/local/lib/postgresql93/bin/initdb -D /opt/local/var/db/postgresql93/defaultdb'

Simply run these 3 commands, and on correct DB initialization, postgresql will warn you:

WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.

Success. You can now start the database server using:

    /opt/local/lib/postgresql93/bin/postgres -D /opt/local/var/db/postgresql93/defaultdb
or
    /opt/local/lib/postgresql93/bin/pg_ctl -D /opt/local/var/db/postgresql93/defaultdb -l logfile start

Use the launchd plist installed by MacPorts in the right place:

$ /usr/bin/sudo launchctl load -w /Library/LaunchDaemons/org.macports.postgresql93-server.plist

check that everything is ok thus far:

$ telnet localhost 5432
Trying ::1...
Connected to localhost.

ctl+C
Secure postgresql (a vulnerabilities DB should be of very restricted access)

$ cd /opt/local/var/db/postgresql93/defaultdb

edit pg_hba.conf to remove the lines:

local   all     all                     trust
host    all     all     127.0.0.1/32    trust
host    all     all     ::1/128         trust

and replace them with:

local   postgres        postgres                trust
local   msf_db          msf_user                trust

Restart postgresql in this mode limited in access through UNIX domain socket.

$ /usr/bin/sudo launchctl stop org.macports.postgresql93-server

Select the correct postgresql version

$ /usr/bin/sudo port select postgresql postgresql93

Configure the Metasploit DB to use

Let's say the user to use will be msf_user,
with password pass_pass and the DB will be msf_db.
Switch to user postgres:

$ /usr/bin/sudo /usr/bin/su postgres
$ createuser msf_user -p
Enter password for new role: pass_pass
Enter it again: pass_pass
$ createdb -O msf_user msf_db

These 2 commands won't display anything, this means everything is OK.

5. Metasploit

Install Metasploit

$ /usr/bin/sudo mkdir -p /local/Metasploit
$ /usr/bin/sudo chown BOB /local/Metasploit
$ cd /local/Metasploit
$ git clone --depth=1 git://github.com/rapid7/metasploit-framework .

2nd PATH switch

Insert within ${HOME}/.profile, within the section
which is always run and after any other PATH or MANPATH definition:

PATH=/local/Metasploit:${PATH}
export PATH

PATH switch:

$ . ${HOME}/.profile

Update Metasploit:

 $ msfupdate

Configure the DB access:

$ cd /local/Metasploit/config
$ cp database.yml.example database.yml
$ vi database.yml

to include there this uniq block:

production:
  adapter:      postgresql
  database:     msf_db
  username:     msf_user
  password:     pass_pass
  port:         5432
  pool:         75
  timeout:      5

To get an automatic connection at each start, include the following line within the metasploit initialization script:

$ cat >${HOME}/.msf4/msfconsole.rc <<eof
db_connect -y /local/Metasploit/config/database.yml
eof

Check that everything is working:

$ msfconsole
msf > db_status
[*] postgresql connected to msf_db
msf >

Help yourself a cup of champaign :).


Using Lynx on potentially malicious websites After needing to refresh how to unpack an android ramdisk, the site I remember having good information comes up with something similar to this:

Being cautious, but still wanting to get what was on the page, I turned to lynx.

Finding that lynx -dump http://website.com > /where/i/want/it would get what I need, I am wondering: Am I still open to some sort of attack?

On this Mozilla page it seems pages like this are geared more towards tricking someone into clicking something then downloading malware.

Would I be safe from other common attack methods as well? Since I am just pulling off text, I am assuming lynx doesn't run many of the scripts necessary to start rogue downloads etc.. But I don't know a whole lot about these things =)

You are greatly reducing your surface of attack by using lynx or similar, for example they don't run Javascript nor try to decode and display images so any vulnerabilities in these components don't affect it.

But in theory, you are still vulnerable. Even in Lynx there are still components that parse HTML, interact with the network, keep track of cookies, etc (tip: use curl or wget to just download the page without even parsing it to be even more careful). That is still quite a big attack surface, though I would consider it safe enough at this point. Maybe not safe enough against a targeted attack from a powerful attacker, but definitely safe enough for random Android websites.

Note that while the site itself didn't compromise you, any tools you would download and execute from there could be malicious, including the Android ROM or whatever you wanted to download - I suggest you carefully check out why was the site blocked and make your own assumptions about whether it's safe (I would say it's not safe unless it comes from the phone's manufacturer, Google or a known open-source project and I can verify the file is authentic by checking hashes published over HTTPS or a GPG signature).


How to classify DNS packets coming to clients as spoofed or not? Without being bothered by a DNS server that is using newer version of the DNS protocol. I want to monitor DNS packets on client machines and want to classify them as being spoofed or not.

Is there any way to do this?

It's probably impossible to look at a single DNS packet and know if it is spoofed or not. But, if this is a DNS reply packet to a system without a matching DNS request a short time before than this is probably spoofing. And if there is a DNS request originating from the machine but the incoming DNS reply does answer the DNS query but does not match in the DNS request in port and id than this is probably a spoofing attempt too, especially if there are lots of these mismatching packets.


Is it secure to have an iPad app run a webDAV server on localhost without authentication? I have two iPad apps running on the same device.

One is hosting a webDAV server on http://localhost:8080 without any authentication (the server is active whilst the app is foregrounded, and for a few minutes while it runs in the background). Does this mean that only other apps running on the same iPad will be able to access the server? Is this secure from outside attacks?

The second app reads and writes files from the webDAV server using GET, PUT, and PROPFIND.

Thanks in advance.

This is mostly secure.

To intercept localhost traffic an attacker would need root privileges and at this point you've already lost as the attacker can also read and modify memory at will - no amount of cryptography will help you as the attacker will get your confidential data straight out of memory.

The only issue I see is that you can't prove it's indeed your app that you're talking to. What if another app suddenly starts a server on the same port ? To mitigate this you'd need to generate a key and a self-signed certificate on the first run of the app, and make whatever other browser/app that talks to that first app trust the cert. If some malicious app starts a server on the same port, it wouldn't be able to impersonate your real app.

Finally this seems like a crude way of doing IPC between apps - why not rely on what the OS already offers like App Groups - if you're the developer of both apps you can make them share the same group so they have some way of doing IPC as well as having shared storage :

  Use app groups to allow multiple apps access to shared containers and allow additional interprocess communication between apps. To enable app groups, in the Capabilities pane, click the switch in the App Groups section. You can select existing app groups from the table or add app groups.


Create a easily decryptable message For programmers day, I want to create an encrypted message for colleagues. It should be easily decryptable by the most part without much experience in encryption. Can you tell me an algorithm which is easily guessed and the message revealed?

A substitution cipher (A -> K, B -> C...) should yield rather quickly to frequency analysis, if the plaintext is a natural language text of sufficient length. It helps if they can guess a partial plaintext (the message starts with "Hello", or ends with "glory to arstotzka" oslt.). Leaving the spaces between words intact would be an instant giveaway for shorter words.

You mentioned programmers, so I wonder if you can expect your solvers to create a program to e.g. brute-force a limited keyspace. They'd need to know or find out the algorithm, though. Also, natural language text ciphered with a stream cipher (xor) using a repeating keystream is rather easily solvable since the binary representations of spaces and letters give away parts of the plaintext when looking at ciphertext bytes enciphered with the same keystream byte. Though that may require some background knowledge to get the right insight.

All in all, a good puzzle would depend on accurately guessing the level of the solvers. One possibility would be to build the problem in parts, starting with easier systems and progressing to harder ones. Any book/source on historical ciphers would likely have many examples on what to use.


Snort rules question I just noticed my snort rules fired today on this, on a brand new ossim server I was testing.
"shellcode x86 inc ebx noo" on with the source ip from Canada. Why might a brand new server, behind a firewall and a NAT router, see an alert like this coming from an external IP?

For sake of argument, let's assume you're referring to the rule mentioned by Mark in his comment. This works out well since when doing a full text search of your quoted text across all VRT and ET rules, it's the only one I found as well. It is sid 1390, found in the file shellcode,rules for those keeping track at home.
The full rule text is:
alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"SHELLCODE x86 inc ebx NOOP"; content:"CCCCCCCCCCCCCCCCCCCCCCCC"; classtype:shellcode-detect; sid:1390; rev:9;)

Thankfully, this is a nice and simple rule. For the same of analysis let's also assume that this device is on your border and the IP variables have been properly configured.
So, this rule gets checked against every IP packet that comes into your organization. Already it seems pretty noisy. It looks in the payload section of the packet for the a string containing 25 consecutive 'C' characters. The reason for this is that this character maps to the inc ebx instruction for the x86 architecture (as implied by the name of the rule). In the x86 architecture this instruction is functionally equivalent to NOP, and as such can be used as part of a NOOP slide, but is slightly less obvious.
This specific rule, and many of the shellcode rules in fact, are well known generators of false positives since they can often be generated by downloading binary files. The traditional tuning advice is to disable these rules on web ports.
So, depending on your risk threshold, you can either

Disable the rules entirely
Modify the rule to ignore packets on "web ports"

Disabling the rules is easy, and something you should be well acquainted with if you're attempting to make reasonable use of an IDS at all. Modification can be a little trickier.
Tuning By Port Filtering
Depending on your version of Snort, you should already have two variables set in your snort.conf that will be useful. One is HTTP_PORTS and the other is SHELLCODE_PORTS. By default, they're set to rather basic values.
# Ports you run web servers on
portvar HTTP_PORTS [80,8080]

# Ports you want to look for SHELLCODE on.
portvar SHELLCODE_PORTS !80

What I would recommend is changing HTTP_PORTS to whatever you actually use in your environment, and then setting SHELLCODE_PORTS to the inverse of that, so something like:
# Ports you run web servers on
portvar HTTP_PORTS [80,8080]

# Ports you want to look for SHELLCODE on.
portvar SHELLCODE_PORTS !$HTTP_PORTS

Then you can modify the Snort signature to use the appropriate port variable.
alert ip $EXTERNAL_NET $SHELLCODE_PORTS -> $HOME_NET any (msg:"SHELLCODE x86 inc ebx NOOP"; content:"CCCCCCCCCCCCCCCCCCCCCCCC"; classtype:shellcode-detect; sid:1390; rev:9;)

So now this will exclude any data coming from an external web server, so say downloading an executable from a vendor website. It is best to keep in mind that since this rule is not stateful, a malicious attacker could craft their exploit in such a way as to avoid the rule.
Tuning By State Tracking
Alternatively, we could tighten up the rule by forcing it to be stateful instead. Let's remove the port restriction and tighten up the rule to only to outside initiated communication by adding the flow keyword, turning that rule into:
alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"SHELLCODE x86 inc ebx NOOP"; flow:to_server,established; content:"CCCCCCCCCCCCCCCCCCCCCCCC"; classtype:shellcode-detect; sid:1390; rev:9;)

So now the rule will look for at least 25 consecutive 'C' characters on any outside initiated communication. So while we'll now see the cases where the malicious user spoofs their source ports, in an effort to bypass firewall restrictions, we will miss cases where the exploit code is downloaded from a local host.
Analysis Paralysis
In both cases, there are obvious ways to bypass the detection routine, so which direction you choose depends entirely on your risk profile and your threshold for acceptance.


Can we use Data Loss Prevention (DLP) to Protect encryption keys? I would like to setup DLP in Network taping mode to identify and protect if someone is sending the encryption keys outside to organization. Is it possible to configure such rule in the DLP policy?

I did some search and while I feel it depends on how you can find a common string / type in the file / date you want to block. Most DLP's - I checked with symantec offer ability to block an "encrypted" file but not the keys for encryption itself. If the user sends encryption keys in a particular file format such as .asc you can block those but if they're copy pasted in a document, my gut feeling is that there's no way you can block it unless you find a pattern (impossible given the variables involved in cryptosystem.)


Is there any benefit to hashing sortcodes + account numbers? We have a database of sort codes (6 digit numbers) and account numbers (8 digit numbers) that we use to reconcile monthly accounts with the table of supporters.

There is nothing in the data received from the bank that uniquely identifies the supporter, other than the sort code and account number. ... I know, it's annoying.

While this data is not as sensitive as card data (and not subject to PCI-DSS), it's still pretty sensitive and I'd like to find another way to do the reconciliation to reduce the liability of having all this data.

Combining sort code and account number gives up to 10^14 possibilities.

Is there a way (using a reliable and established PHP function) to hash the data and only store the hash, that would allow me to take a monthly file of -say- 1000 records and match them up to the hashed data? Or is there really no point and instead focus on hardening security around this db?

The security advantage I'm seeking is that the database does not have a ready-to-use list of people's bank details. The transactional monthly bank statement data can be considered to be of short lifespan (it is received encrypted, decrypted, processed, deleted).

I've read a helpful detailed comparison of hashing functions but obviously here we're not talking about password, and in effect we need to be able to crack them every month! Hmmm.

EDIT: Conclusion

Thanks to the answers below, here's what I plan to do:

Set-up

Create a map for sort codes and account numbers to random ids.
Replace real data with mapped data.
Encrypt this map using PHP's Mcrypt AES 256 with a user-provided key never stored on server
Store the encrypted map on the server.

Now: you can take the database, you don't get the data, or any way to decrypt it by brute force, thanks to the random map.

You can take the map also and figure out how it works (not relying on obscurity), but you still need to be able to crack the encryption to get access to the map. This feels like a suitable level of risk.

Reconciliation

Decrypt the PGP content from bank locally.
Over SSL, upload the month's transactions and also provide the decryption key.
Server decrypts the map, applies it to the uploaded data, stores mapped data for later processing, deletes raw uploaded file.
User deletes decrypted bank data locally.

This means the key and decrypted map are only ever in RAM. The month's transactions are temporarily stored on disk, but that's an acceptable level of risk IMO (could use a secure deletion method like bleachbit etc.).

Updating the key is as simple as provide existing and new keys, decrypt map, encrypt map, store map.

If there was concern that the decrypted map had been compromised, this could be rebuilt, too, although it's more effort as it means updating all the stored data.

Be wary of hashing things where people might determine characteristics of the input. One company used MD5 of taxi IDs for anonymizing, which was quickly reversed. Yes, you could try some home-baked hash modification that would make it less obvious than just a straight MD5, but that's security through obscurity. Solving almost any hashing function for every 8 digit account number is trivial, at which point your data is as good as plaintext. Concatenating account numbers with the sort code isn't going to be much better.

What you should do instead is to make a table/program/whatever that maps your sensitive data to random IDs. Your system would require access to that table/program to do the conversion, you can take steps to secure that table/program (like storing it in a truecrypt volume) while you work with the truly anonymized data.


How secure are self decrypting HTML files for data storage? I recently came across a JavaScript self decrypting archive. Is it secure enough to be used as a portable password storage tool? The author has even challenged it to be cracked.

At least the author wrote a rather clear page on how his encryption works. Notwithstanding, this looks like a rather old-style homemade stream cipher, which is not good news, since most of such systems have been thoroughly broken. It appears to consist of a basic LFSR subsystem (two LFSR with key-dependent polynomials; the bit about the polynomials operating in "reverse direction" is a red herring, because this subsystem is still wholly linear) and another LFSR which acts as a non-linear selection engine. There are a few select designs which roughly look like that and appear to offer a non-negligible cryptanalytic resistance (e.g. the Alternate Step Generator), but this comes at a price, namely that you need quite much more than n internal bits of state if you want to achieve a 2n security level. Also, many such designs turned out to be weak.

We can trust in the resistance of a cryptographic algorithm based on the combination of the following properties:

The designer is known to be very good at designing algorithms (e.g. his name is Rivest).
The design got wide exposure, such as being published in some high-profile conference and/or being deployed at a large scale.
Several years have elapsed, and nobody found any issue.

This design is a bit lacking on the three points.

Edit: I had not noticed it (I need more coffee in the morning) but the generated stream is deterministic for a given password. This means that if you encrypt two archives with the same password, you are in the infamous "two times pad" situation, and you have basically lost.

Another point is that the password is derived into a key with only a pair of invocations of MD5. MD5 is very fast; a good, but off-the-shelf and not utterly expensive GPU can evaluate MD5 at a rate of roughly one billions per second. If the first bytes of the encrypted data are guessed by the attacker (since cleartext is supposed to be Javascript, the first bytes are probably "var" or "function"), then the whole thing is vulnerable to dictionary attacks, aka "exhaustive search on password" (trying out potential passwords until a match is found). It is possible to have a big fat random password which defeats dictionary attacks, and a human brain could still remember it with some effort. But most passwords are weak in that respect. Also, no salt: for a given password, you always get the same stream. Therefore, one could precompute the first bytes of the stream for each potential password, and afterward cracking any instance would be a matter of a few lookups in the table (the table could take the form of a rainbow table for more compact storage).

For the password-handling part, this scheme is definitely weak.

The use case is also dubious. Since this is Javascript code in which the user enters his password, this is vulnerable to active attacks: an active attacker could simply alter the Javascript code, so that when the user enters his password, a copy of the password is also recorded somewhere (e.g. the decrypted data -- which is supposed to be Javascript itself -- gets an additional code snippet which prints out a hidden <img> tag with a URL pointing to an attacker-controlled server and encoding the password).

To defeat active attacks of that kind, the solution is known, and that's SSL. The "self-decrypting archive" should be served only over HTTPS. But if HTTPS is used, why would self-decryption be needed ? Instead, have the server give the sensitive piece of Javascript only after having duly authenticated the user, with the password. This is a very common model, existing Web servers implement it out of the box, and it is stronger since it thwarts offline dictionary attacks (from the outside, the attacker cannot "try passwords" at the maximum speed of his GPU; he has to ask to the server for each guess, and the server can answer as slowly as it wishes).

Summary: I recommend against using this piece of code. I still note that, at least, the designer of SDA appears to have made commendable efforts at documentation, and to be sane -- sanity alone puts him in a minority, among the crowd of cipher designers on the Internet.


Client identification using client certificates I have the following scenario:

Several independent embedded servers (Linux/ARM/lighttpd)
Several independent controlling devices (win32/iOS/Android)
Each server should have at least one controlling device
Each controlling device can control one or more servers
None but the controlling devices should be able to contact servers

I understand I could use Client Certificates to ensure "device/server pairing", but I am unsure if at all possible and (eventually) how to setup my systems to fulfill the following additional requirements:

Hassle-free Client Certificate installation: I mean I would like to have some automated procedure initiated on the server (possibly via physical push button) which will create and deploy a specific Client Certificate (something akin to "Wi-Fi Protected Setup").
Role-based certificate creation: each controlling device should have a "role", meaning it can perform a defined set of operations on the server; essentially I need just to embed some data in the certificate at creation time.
Client Certificates should be expiring and revocable (I think this is standard, but must be allowed-for while creating the certificate itself).

Real question is how to setup (1), where I have little clue. I have searched the Internet, but I found only the "normal" way (generate cert, self-sign, manually import into browser) which is way too complex for my Customers :( ; I was hoping to be able to generate a URL (or print a Qr) that, entered on controlling device, would "automagically" configure its browser (possibly with just some simple "OK" confirmation). Is this (or something equivalently dumb-proof) possible, somehow?

Advise and comments on the other issues are welcome (of course!)

NOTE: I am not requiring bank-proof security, just a reasonable compromise; focus is on how much I can achieve "without bothering users" (entering a password is considered bothersome, unfortunately).

I'been digging in the Certificate field recently, and I know it's been a month since you asked, but I hope this helps you some way.

In order to give each of your customers a certificate, You'll basically need a server with its own selfsigned Certificate. This server will "give" your customers their new Certificate.
The flow would be something like this:

1) [FRONTEND] The customer generates a keypair and sends the public key to the server, asking for a new certificate.

2) [BACKEND] The server generates a new certificate based on the customer's public key, and sends it back to the customer with a specific header saying it's a certificate.

3) [FRONTEND] The customer "download" the certificate, the browser knows it's a certificate and prompts the customer to install it on the browser with just a click.

For (1), there are ways to do it with just a click. For most browsers you can use the "keygen" html tag, for IE sadly you have to use ActiveX.
For (2), you'll need some kind of CA Management module, there are some free ones out there, like OpenCA or EJBCA.

It could be a little hard to implement, but it gives an undoubtable authentication for your customers, as they are using certificates signed by you, and it's really pretty easy on the customer side, it doesn't need more than a 2 or 3 field form and two clicks.


Which remote desktop protocol offers the smallest attack surface? I am trying to "outsource" potentially dangerous applications such as web browsing to a separate Linux machine sitting in its own network segment and which is isolated by a rigorous network firewall from our internal network, thus I am trying to build a "remote-controlled browser". Since I am in the early planning phase, I wonder which remote protocol to choose best for remote access to such a machine. I have to deal with a potentially malicious server and I want to protect the client (Windows or Linux) which accesses it.
Which remote control protocol would you recommend for a small attack surface? I can think at the moment of

RDP
VNC
SPICE (from the proxmox hypervisor)
NX (Nomachine)
X2GO
XPRA via HTML5

It is clear that the more lightweight a protocol is, the more suitable it is. However, I would prefer to be able to also stream video + audio over it (which might rule out some protocols).

You're asking a question about protocol security, but it's not entirely clear how you would compare these as they aren't exactly equal. You're also not considering the supply chain security of the software that will speak these protocols. It hardly matters if VNC were the most secure protocol if you're running a 20 year old VNC server that's never been audited and is full of buffer overflows on your linux machine.
Additionally I don't think you have put sufficient effort into the threat modelling. If someone compromises your browsing machine and hooks the SSL traffic, they will still be able to see all your private data, usernames and passwords. Which might allow them to chain further attacks against your internal network infrastructure.
Additionally the browsing machine is likely situated behind a SOHO grade router which are notoriously vulnerable. If the same router is shared between the networks then the attacker could affect one network from the other by say, changing the DNS settings.
IMHO you should decide what you want to protect against, how you will remain secure if the browser server gets compromised and then consider the holistic view of remote management, including supply chain, not just a popularity contest of protocols based on people's gutfeel/opinion.


Can you encrypt memory of server which hold luks keys? I have a cloud VM. It's Centos 7 and I used full disk encryption during install. I also installed dropbear SSH to remotely unlock said server in case of a reboot. No one but me have administrative access to the machine. Is there a way to prevent ISP to sniff on my data? I think when I decrypt the server so it can run it stores decryption keys in memory. If my ISP will "snapshot" this machine it will get an image of the memory and can extract the keys, can it? Is there a way to prevent this? Can you encrypt memory?

There are some technologies that encrypt memory accesses in hardware, like AMD's Secure Memory Encryption (white paper, article on LWN), but it's mostly targeted against cold-boot attacks.

The general problem here is, that you'd need to save the encryption key somewhere to be able to use it, and then it can be stolen etc.
(The same LWN article describes Intel's "Software Guard Extensions", which seems a bit closer to what you'd like but has a hint of DRM smell on it, and apparently requires signatures from Intel...)

If you're running VMs on other people's machines, then you don't own and can't control the hardware, so not putting sensitive data (at least not sensitive keys) there is about the only option you have.


Strong Cryptography in PCI PA-DSS In PCI PA DSS document, the phrase “Strong Cryptography” is often repeated but I couldn’t find a clear definition for that. Is there any document or PCI standard for that?

As the document told you:

Please refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for definitions of “strong cryptography” and other PCI
DSS terms.

Reading that document, we see that it is (v3.1):

Cryptography based on industry-tested and accepted algorithms, along with strong key lengths (minimum 112-bits of effective key strength) and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). See Hashing
At the time of publication, examples of industry-tested and accepted standards and algorithms include AES (128 bits and higher), TDES/TDEA (triple-length keys), RSA (2048 bits and higher), ECC (224 bits and higher), and DSA/D-H (2048/224 bits and higher). See NIST Special Publication 800-57 Part 1 (http://csrc.nist.gov/publications/) for more guidance on cryptographic key strengths and algorithms.
Note: The above examples are appropriate for persistent storage of cardholder data. The minimum cryptography requirements for transaction-based operations, as defined in PCI PIN and PTS, are more flexible as there are additional controls in place to reduce the level of exposure. For example, double length TDES keys used in unique key per transaction implementations as defined in ISO 11568 for key derivation or transformation (e.g., DUKPT) are considered to provide an equivalent level of strong cryptography because a single unique key is generated for each transaction.
It is recommended that all new implementations use a minimum of 128-bits of effective key strength.


How to avoid identity theft at key signing parties? Let me begin by distinguishing two kinds of identity theft:

Conventional identity theft (e.g. using credentials from ID documents, bank accounts, etc, to commit fraud or other mischief).
Cryptographic identity theft (e.g. using a PGP certificate (aka "key") to impersonate another PGP/GPG user without their permission).

Key signing parties (KSPs) are intended to make cryptographic identity theft harder, but as they typically require exposing credentials from government-issued ID documents, bills, or similar, to people who would not normally have access to them, they would seem to increase the risk of conventional identity theft.

I can think of a couple of ways to mitigate against this increased risk:

Covering passport numbers, dates of birth, driving license numbers, etc, before showing the document at a KSP;
Only signing keys belonging to people known well enough that the showing of additional credentials is not required (e.g. family, or long-standing close friends), and expecting the same in return;

However, the first might reduce trust, and the second would seem to make KSPs unnecessary.

So, I'd be grateful for others' views on how people should gain the benefits of KSPs without putting themselves at increased risk of conventional identity theft, and for pointers towards any research that has addressed this.

At a key-signing party, you show documents, you don't hand them over, nor is there an opportunity to copy them.  Someone with an eidetic memory and an evil side might be a risk.  However, eidetic memory is rare in adults.  (So is evil, happily.)

So, specific advice in answer to your question: a key-signing party should have guests known to the host, or "second order" guests, that is guests known to a guest in attendance who is himself known to the host.  Also, the host will necessarily keep a list of the guests in order for the KSP to function.  I think the risk is small.


What methods can be used to verify identity against a database? I have a database with individual contact data for students... this data includes name, address, phone number, birthdate, etc. (no social... that would have made this too easy apparently, ha ha)

I would like to allow their parents to access their data from home, and be able to view and edit it.  Obviously, security is a huge priority here; I don't want a creeper gaining access to their address or somesuch.

Are there any methods that I could use that:

Don't require me to generate a code or input new data for them manually (this is just impractical, and requires me manually verifying each student/parent combo).
Could not be easily mined from, say, a facebook account (name and birthdate are both easily accessible for example).
Don't lean on data that is more highly likely to be inaccurate (a street name is much more likely to be misspelled than a last name for example... and by the same token, first names aren't always trustworthy [some people go by a middle name, but might have their first in there, or a nick name, or whatever]).

I'm stumped... I'm hoping there's a technique here I'm not thinking of, but perhaps there is simply no way to do this without making it much too easy for someone to access it.

Since you have postal addresses send them a letter via mail merge that contains a long random code. They enter the long random code and perhaps some other information they should know such as D.O.B. to validate they have physical possession of the letter and some knowledge of the student.

This tells you they are:

Someone with access to the mailing address
Reasonably the parent or guardian if addressed appropriately
Or a corrupt postie ;) Or inquisitive sibling...

Once they have passed the initial authentication check require they enter an email address and password. Once this has been verified invalidate the code you mailed them. A unique id - either sequential or a guid - should be generated against each user in the DB. This becomes their unique identifier and you can then associate users who should have access with the record.

Since the code you generate is effectively a password good security practice for storing passwords should be used for storing the code - suggest bcrypt ( http://en.wikipedia.org/wiki/Bcrypt ) or PBKDF2 ( http://en.wikipedia.org/wiki/PBKDF2 ) with a suitable salt and work function.

Another potential approach would be Knowledge Based Authentication ( http://en.wikipedia.org/wiki/Knowledge-based_authentication ) - you ask them things only they would know. This requires you to have accurate records of things they should know! (e.g. all the grades from their childs last report card).

Hope that helps.

Regards
Andy


PCI DSS Compliance for a Level 4 organization We are a small company and process less than 500 Credit Card transactions each year so we fall under Level 4 category merchants. The company heads wants to make sure that we are PCI compliant at all levels. I see that we are storing the credit card data in one of our databases but the PAN number is encrypted using RC2 encyption when it was initially developed years ago. I still feel that the RC2 encryption is vulnerable to attacks though we use SSL connection to transmit the data.

I have a few things in my mind as follows.

Tokenization
Removing Card data from our database and only transmit details to the payment gateway.
Secure Key Storage for the encrypted card Data.

I checked with the business and they said that the option 2 to remove card data is fine as they do not need to store data, but since there are some recurring transactions, my question is will that be affected if card data storage is removed??

If I go with option 3 of securing the keys used to decrypt the data, I see that there is a lot of procedures that needs to be followed as to implementing a commercial key management system etc.

Can you please suggest as to what is the best way of getting around this and be compliant.

The best over all solution is to use a commercial payment handling service that deals with all of that for you. For that transaction volume, the danger of having card data stored on prem out weighs your need for the data.

If this is a retail business, I would suggest something like square, which would essentially put the responsible handling of data in their court, and their rates are very friendly to the small business world in comparison to other options.


How to handle UDP abnormally disconnection in DTLS？ DTLS-UDP is used between client and server.

If the client ends abnormally，how does the server know that the client is gone?

i have read rfc6347 and find nothing about that.
thanks in advance.

As commented by dave_thompson_085, DTLS is connectionless.

In order to detect a client which has stopped communicating you would have use a method of detecting a client is no longer sending traffic, such as a heartbeat or keep alive. RFC6520 was written exactly for this purpose.

The reason it's not in the DTLS RFC is because the protocol is connectionless by design.

It's also worth noting that although Heartbleed was a bad bug, it's now been patched and it shouldn't discourage you from using OpenSSL. There are also OpenSSL alternatives such as LibreSSL

(Note: I would have put this as a comment but I don't have enough reputation at the moment)


Breaking Wifi password knowing its length of 8 [A-Z] alpha (upper-case) characters using Hashcat I got the WPA handshake, now it's turn to crack the password using Hashcat. First, I wanted to make a wordlist of passwords [A-Z] the length of 8, but Crunch (the tool in Kali Linux) said it will take 1TB of storage that I don't have available, so I gave up that way. Is there any way to generate passwords (example: ABCDEFGH) and delete them after its use one by one, during the cracking process?

How long does it take to crack the password with i5-3320M CPU using Hashcat?
Is there any other way you recommend?

Is there any way to generate passwords (example: ABCDEFGH) and delete
  them after its use one by one, during the cracking process?

Try a mask attack where you've defined the mask as 8 digits of uppercase:

hashcat -m 0 -a 3 hashfile ?u?u?u?u?u?u?u?u

(replace -m 0 with whatever mode you're cracking)

There's an excellent tutorial on mask attacks here.


How does webserver informs the browsers of the https capability? How does webserver informs the browsers of the https capability?

if we type in microsoft.com (which is a http request by default) firefox fetches/the server serves the following page https : // www.microsoft.com/en-in/  .The original request is in http.
we see a Http get request for http : //microsoft.com/
with Upgrade-Insecure-Requests: 1 flag (the clients willingness to go to a secured connection)
next we see a http 301 moved permanently. this packet contains the location field as http: // www.microsoft.com /
next we see the client starting out a TLS handshake to start out the https session and eventually get the https page

where can we see the server informing the client of the https capability or redirecting for https port 443?
can we suppress the Upgrade-Insecure-Requests flag so that we get a http response?(assuming the server doesnot automatically redirect to https)

attached is a wirehark capture. filter using the following

(http contains microsoft) or (ssl contains microsoft)

In this case, it's a pretty simple series of HTTP redirections:

┌─[jamesph@ilmr] - [~] - [Tue Jan 24, 11:45]
└─[$]> http --head 'http://microsoft.com'
HTTP/1.1 301 Moved Permanently
Content-Length: 148
Content-Type: text/html; charset=UTF-8
Date: Tue, 24 Jan 2017 19:45:48 GMT
Location: http://www.microsoft.com/
Server: Microsoft-IIS/8.5
X-Powered-By: ASP.NET

┌─[jamesph@ilmr] - [~] - [Tue Jan 24, 11:45]
└─[$]> http --head 'http://www.microsoft.com'
HTTP/1.1 302 Moved Temporarily
Connection: keep-alive
Content-Length: 0
Date: Tue, 24 Jan 2017 19:45:56 GMT
Location: http://www.microsoft.com/en-us/
Server: AkamaiGHost
X-CCC: US
X-CID: 2

┌─[jamesph@ilmr] - [~] - [Tue Jan 24, 11:45]
└─[$]> http --head 'http://www.microsoft.com/en-us/'
HTTP/1.1 301 Moved Permanently
Connection: keep-alive
Content-Length: 0
Date: Tue, 24 Jan 2017 19:46:03 GMT
Location: https://www.microsoft.com/en-us/
Server: AkamaiGHost
Set-Cookie: akacd_OneRF=1493063163~rv=66~id=28df10e9d3a3627dfc38acff7feb884a; path=/; Expires=Mon, 24 Apr 2017 19:46:03 GMT
X-CCC: US
X-CID: 2

(I'm using httpie, a utility that's like an improved version of curl for cli usage.)

http://microsoft.com 301 redirects to http://www.microsoft.com, which 302 redirects to http://www.microsoft.com/en-us/, which 301 redirects to https://www.microsoft.com/en-us/.

In general, HTTP redirects are how many websites get users onto https.  Tools like sslstrip can sometimes foil these attempts, since the initial connection can be MitMed because it's not protected by TLS, which is why sites are increasingly starting to use HSTS headers, at which point the browser stores the information that the site should be accessed over https and sends the request there from the start (rather than assuming http when the protocol isn't given).


Pin + guid in URL secure for a web app? We have an ongoing project at work in which the security is a hot topic of debate. The whole site is SSL and proposed auth process is like so:

User receives a non-unique 4 digit pin number in person.
User is emailed a URL with attached long(40 char or so) GUID.
User visits URL and enters pin to authenticate. (pin is salted/hashed)
User is prompted to set a password. (properly salted, hashed and stored)
Upon visiting the site via the guid link, they will now be prompted for email/pass rather than pin. They may also visit the generic URL sans GUID and login with UN/Pass

A security consultant told us this is not good enough (I don't know the details of why at the moment). It seems sufficient to me. We don't set a password from the start because it would be impractical UX, and we change from PIN to Password so the user can use a generic login page without the guid URL.

Using the GUID as unique identifier for the user instead of the email address has benefits against low-power attackers. The URL-with-GUID has been sent through email, so it cannot be considered as really secret. Motivated attackers will spy on the network lines and see that email. However, amateurs or automated attack bots, while not being able to read other people's emails, may "guess" email addresses, but not random GUID.

The GUID has thus any relation with security only insofar as it is unpredictable, and then it would bring any good only against attackers who are not very powerful. Using the GUID does not harm, but don't believe that it really adds much protection. You might want to make sure that the GUID is generated wit the version 4 algorithm, i.e. 122 bits from a strong PRNG: though GUID aim at uniqueness, you want unpredictability, which is another beast; version 4 GUID ensure both.

Keeping in mind that the GUID is not (really) secret, your system can be described as such: there is a one-time registration password, which is a four-digit PIN. After registration, a normal user-chosen password is used.

The main problem is that the four-digit PIN is too easy to guess: an attacker only has, on average, to try 5000 of them before hitting the right one. You can mitigate this problem by deactivating the PIN code after, say, three wrong attempts for a given GUID; that's the model of smart cards, with your server as the card. However, this will thwart only attackers who do an online brute force.

It unfortunately happens, occasionally, that some attackers obtain a glimpse at some parts of the server database. This is a frequent result of SQL injection attacks, for instance. Discarded old hard disks are also a classic source of such leaks. This is the very reason why you envision storing not passwords of PIN codes, but only hashed versions thereof.

But password hashing, even if done properly, only slows down attackers. If the iteration count is set so high that it takes a full ten seconds of computing for your server to verify a PIN code (and ten seconds are a very long time for a waiting customer), and attacker will "just" need 50000 seconds worth of computation, with the same hardware, to "try" 5000 possible PIN codes. Since the attacker will throw in a couple of multi-core PC, he will probably get down within an hour or two. That's not a lot.

I advise using a longer PIN code, say 8 digits.

To sum up: your GUID is not "secret enough" to tolerate a four-digit PIN, even for a one-time registration page. Using a GUID instead of the email address is interesting and you want it to be as discreet as possible (so use "v4" GUID), but even so, four digits are not enough for a PIN when the verifying system is not a tamper-resistant smart card. Use eight digits (or more). Since the user will type the PIN code only once, he can tolerate a rather long sequence (Microsoft could make users type 25-letter activation keys, so I don't think that 8 digits for registration would be too much to ask).


Server side Excel file security I need to write an application that will interact with files uploaded from untrusted sources (users).  Specs say I must support CSV and Excel. If I allow a user to upload an Excel file to the server and handle opening, processing and saving the file server-side, what kind of security concerns am I opening myself up to? What kind of mitigations can I bring to bear on the problem or is this fundamentally unadvisable? (For these questions, assume that web server role is running under a least privilege account.)

Edit Clarification:

In particular, I am concerned about the excel file... do I have to worry about macro execution, or viruses, or it not being an excel file?  I would be opening this from a C# written back-end... what risk is there attempting to read this through an excel interpreter?

I can think of following scenarios:

Since you are processing your data and then carrying out a DB call, you should ensure that you used prepared statements in your webserver. That will take care of all your SQL Injection attacks
If you are presenting the data on your webpage, then ensure you are sanitizing your input to prevent a Stored XSS attack.
An attacker can change the order of the cells in CSV file inorder to crash the server. You should make your code independent of the cell ordering in CSV file (it is very easy to implement). It is also a good to have feature

In your case, you should be worried about secure coding of your application and handling different edge cases in the structure and contents of the file.
IMHO All the applicable attack vectors here will be related to the data present in the files.


What are some good, free tools to run automated security audits for PHP code? I've been looking for some time now and have come up short. The most promising I found was Spike PHP, which seems to no longer work. I'm looking to scan my code for potential risks of SQL Injection, XSS, etc. I've gone through most of my code manually, but with a few hundred thousand lines of code, I'm sure I missed things. If possible, are there any tools that can be downloaded and analyze code on my local machine rather than installing to the live server (this isn't a requirement if not)?

There's a static code analysis tool for PHP called RIPS.  I've not had the chance to use it as yet, but it sounds like it's in the right kind of area for what you're looking to do.

On the commercial tool side of things, Fortify SCA has support for PHP, as far as I know.


Way to remove rc4 from Linux Cipher Suites Running this command resulted with the list of ciphers which supports rc4:
/usr/bin/openssl ciphers -v | grep -i "rc4"

What's the easiest way and how to remove specifically ciphers that supports rc4 that I need to execute or where is the configuration file in need to edit on Linux machines?
What's the way to reverse the impact of this command? In case one of the server applications will stop working we will need to revert back to the previous Cipher Suites configuration.

Linux is just an operating system and doesn't understand the concept of “cipher suites”. Each application that supports TLS has its own configuration regarding cipher suites.
For example, for Apache, edit the SSLCipherSuite directive in the configuration file (/etc/apache2/httpd.conf, or wherever your distribution puts it, or one of the files that it includes). For Nginx, edit the ssl_ciphers directive in /etc/nginx/nginx.conf (again, the exact location may vary).
Note that major distributions are likely to ship reasonable defaults out of the box. I would not expect RC4 to be enabled by default on a system where security updates have been applied.


PCI Compliance on scanned images of expired cards What is the requirement on images of expired card numbers?  The images are over ten years old.  If the data is old do I still need to encrypt the data?

PCI DSS doesn't discriminate between expired and active card numbers; it simply says that PAN (the Primary Account Number) being present is what triggers the need for protection:

  The primary account number is the defining factor for cardholder data.
  If cardholder name, service code, and/or expiration date are stored,
  processed or transmitted with the PAN, or are otherwise present in the
  cardholder data environment (CDE), they must be protected in
  accordance with applicable PCI DSS requirements.

You can ask your QSA for an official opinion, but lacking explicit guidance, I suspect most will agree.

An analogous situation would be synthetically generated card numbers (e.g. http://www.getcreditcardnumbers.com/, https://ccardgenerator.com/).  No QSA I've ever dealt with recognized the legitimacy of such card numbers as test data; the card brands do not recognize them as test data.  They are mod-10 legitimate PAN numbers, therefore, they could intersect with a live (issued, non-expired) PAN and are, as such, "real credit card numbers".  The card number itself is the minimum required to make a charge, so PAN is PAN.

The flip side of the coin is - for whatever purpose are you keeping images of decade-old card numbers?  If the data is so useless as to not require protection, what use are you putting it to?  You may wish to re-architect your flow to remove the need for this data.


responding to comment spam My website has several forms which are periodically spammed.
When a submission gets flagged as spam, and is internally rerouted to where spam should go, what is the appropriate response:

show an error
or
show the regular message indicating that the message has been sent like normal

The problem with the first option is that in theory the spammer now knows that his email is being flagged, and he might change tactics such that the heuristics don't catch it
The problem with the second option is that if it is in fact a legitimate user they won't know that there is a problem

It depends on the rate of false positives versus true positives. If most of the time the spam detection blocks legitimate users, the second option would hurt them. But I believe that on most systems, the amount of spam comments are larger than false negatives.
I would keep records on how the spam filter classified posts, and compare the false positives with the true positives, and see if the ratio is acceptable. If it is acceptable, don't let spammers know they are blocked so they will not change their methods and will keep being blocked without knowing.


Owasp Zap's active scan harming the database I want to integrate OWASP Zap security tests in my continuous integration chain using the official Jenkins plugin.

However, since it injects harmful payloads in database, I don't want the database to become corrupted! And it's a huge database. I was wondering how to implement it correctly without corrupting the DB.

Run the active scans against a non-production environment (replica of production). Have a process/script to easily restore a fresh copy of the live database if you break your non-production database during the active scanning.

It is best practice to avoid unnecessary risk on the production site. Also, you can be much more aggressive with your penetration testing against a non-production environment.

You mentioned that your database is "huge". If it is way too large to feasibly copy to non-production in a reasonable amount of time, you could look into decreasing the size of the production database when you copy it into your non-production environment.  This might include trimming the tables that have an excessive number of records that are not required for non-production testing purposes.


Is there any reason not to issue 2FA recovery codes? My ISP give the option of applying 2FA to your account and setting your level of security (from ‘normal’ to ‘paranoid’). However, none of the levels provide 2FA recovery codes.

This is the only service I have so far encountered that offers 2FA but not recovery codes. Before I contact them to ask if they could implement this feature, are there any security reasons not to offer 2FA recovery codes?

This Motherboard article says that without them ‘your security system may do more harm than good.’

This SE answer which says ‘if you print the code and keep in your wallet for example you maintain the secure properties of 2FA.’

There are several implementations to bypass MFA in case you lose control over the "token" of one of the steps in the authentication.

I've seen the use of master passwords, recovery tokens, SMSs or phone calls to a backup phone number, emails, even postal messaging or faxes believe it or not, although the most frequent still remains to have a call with the operations team so that they can reset your account.

There are different problems with every one of them, I don't personally prefer one over the other as long as they are implemented in a right way and you also use them rightfully, so I'd advise you to first know what process your ISP uses to allow for account recovery and if it's secure then enable MFA.


Is sending the same e-mail encrypted and also unencrypted a security risk? Is it a risk, if I send the same email one time encrypted and to another recipient unencrypted?

I wonder if it would be possible to calculate the decryption key (if someone had a copy of both) and then also be able to decrypt other encrypted emails I send?

No, that's not a risk at all with any secure cryptosystem, especially a crypto-system that use asymmetric encryption (e.g., has public keys and private keys) like PGP.  If that was a risk, then any time you sent someone an encrypted message that they have permission to decrypt, they would be able to recover your private key by possessing both the decrypted message and the received encrypted message.

Even with symmetric encryption when used properly (e.g., in well-designed secure software), there will be no risk.  If you use symmetric encryption improperly there will be a risk.  E.g., if you use a block cipher in counter (CTR) mode with a repeated initialization vector, then this has the flaw of the many-time-pad.  That said, re-using an initialization vector in a stream cipher mode like this is a flaw in and of itself and doesn't require an attacker to have access to the plaintext, just multiple ciphertexts with the same IV -- though having a plaintext and ciphertext makes the attack completely trivial.


What clients are proven to be vulnerable to Heartbleed? On several pages, it is re-iterated that attackers can obtain up to 64K memory from the server or client that use an OpenSSL implementation vulnerable to Heartbleed (CVE-2014-0160). There are dozens of tools that reveal the bug in server applications.

So far I have not seen a single tool that exploits the bug in client applications. Is it that hard to exploit the bug at clients? Are clients actually vulnerable or not?

As a matter of fact, yes, clients are vulnerable. So far the attention has been focused on servers as they are much more open to exploitation. (Almost) everyone can connect to a public HTTP/SMTP/... server.

This blog describes how the bug actually works (it mentions dtls_process_heartbeat(), but tls_process_heartbeat() is affected in the same way). This function is used both for clients and server applications, so indeed clients should be vulnerable too.

According to RFC 6520, heartbeats should not be sent during handshakes. In practice, OpenSSL accepts heart beats right after the sending a ServerHello (this is what Jared Stafford's ssltest.py does). Upon further testing, I have discovered that servers can abuse clients by sending a Heartbeat right after sending the ServerHello too. It triggers the same bug.

A proof of concept can be found in my repo at https://github.com/Lekensteyn/pacemaker. From its README:

  The following clients have been tested against 1.0.1f and leaked
  memory before the handshake:

  MariaDB 5.5.36
  wget 1.15 (leaks memory of earlier connections and own state)
  curl 7.36.0 (https, FTP/IMAP/POP3/SMTP with --ftp-ssl)
  git 1.9.1 (tested clone / push, leaks not much)
  nginx 1.4.7 (in proxy mode, leaks memory of previous requests)
  links 2.8 (leaks contents of previous visits!)
  KDE 4.12.4 (kioclient, Dolphin, tested https and ftps with kde4-ftps-kio)
  Exim 4.82 (outgoing SMTP)

It has been demonstrated that 64 KiB of memory (65535 bytes) can indeed returned. It has also been demonstrated that clients (wget, KDE Dolphin, ...) can leak data like previous requests possibly containing passwords.


Secure a publicly accessible REST api We're building a public single page app in JavaScript that talks to a back-end REST service. What we want is for that REST-service to be only accessible from the single page app.

Since it's a public website, we can't / don't want the user to enter authentication details. Any normal authentication mechanism won't work either since any secrets stored in JS are legible to anyone.

I think it's impossible to secure the REST service, since it basically has to be public, but I was wondering if anyone has an idea how you would prevent someone from building a script and reproduce our application using our REST api.

If this is for native apps, you can try the following,

Store an access key in your app bundle. Nobody other than app owner (yourself) can have this.
Change your API so that only requests with the access key set in header will succeed.
Use HTTPS so that nobody can read the encrypted access key.

If you don’t use HTTPS, you can still manually hash the access key with something in the header (only your server and app logic knows how) so that man in the middle can’t pretend to be your app.

If this is for pure web apps,

I would first suggest wrapping the pure web app inside a native app (a.k.a. Hybrid app) so that you can achieve the protection outlined above, by bundling a secret key inside the app. Developing a native app with a single web view inside shouldn't cost too much.

However, if that is not possible, so your app remains a pure web app - here is a potential option,

When server serves the web app, supply an access key.
When the web app makes API call it needs to supply a hashed version of the access key.
How your web app hashes depends on logic that are implemented in minified+obfuscated codes.
Your backend API then validate the hash by applying the same hidden logic to the stored access key to calculate the hash and see if it matches.
You can change the hidden logic and access key as frequent as needed to reduce the chance of someone getting the right hash.

This is of course not bullet-proof but as you know, there is no perfect security and this probably achieves the purpose (and hopefully fits the bill). I would say going hybrid is more cost-effective though.


Why doesn't this XSS attack work? I have a site that has the following javascript that is being executed:

var t=location.hash.slice(1);
$("div[id="+t+"]").text("The DOM is now loaded and can be manipulated.");

I was thinking that if I appended the following to the url:

#message]");alert('test');//

That it would execute the following javascript:

$("div[id=message]");alert('test');//]").text("The DOM is now loaded and can be manipulated.");

But when it runs the console prints the error:

  Syntax error, unrecognized expression:
  div[id=message]");alert('test');//]

Am I wrong to think that my input would generate the javascript that includes the alert?  If so, is there any DOM based XSS attack in the first two lines that I posted?

$("div[id="+t+"]")

That's not JavaScript injection. For it to be JS injection, the attacker-supplied value would have to be written into the JavaScript code from the outside (for example in a server-side templating language or eval in JS itself). That's not happening here, there is no dynamically-generated JavaScript. There's just a plain string concatenation being done inside JavaScript.

It's not client-side HTML injection. For it to be HTML injection, there would have to be attacker markup content written to the DOM. There's not here, only the static string The DOM is now loaded and can be manipulated. which is written using the safe method text() which does not permit markup.

There is an injection problem happening here, but it's only Selector Injection. The JS string variable t is being copied into a CSS selector attribute value at JS runtime. Characters that are special here include ] (which ends the attribute value) and backslash (which introduces CSS escapes).

That's still a bad thing, but the worst you can do with a selector injection is make the application select the wrong element, for example:

http://victim.example.com/page#x],body,div[id=x

resulting in the selector

div[id=x],body,div[id=x]

which would, because of the reference to <body>, replace the whole page with the text The DOM is now loaded and can be manipulated.

Selector injections don't normally lead to DOM XSS. It's conceivable if you could target an element that the application then trusted to execute as code, such as a <script type="text/template">. But when you don't have control of the string The DOM is now loaded and can be manipulated. then there's not exploitation you can do, just annoyance.

You can fix selector injection by \xxx-escaping characters in t that are special in CSS. Better, where possible, is to avoid selector strings and their escaping problems by going straight to the element ID:

$(document.getElementById(t))  // works for any character in t

However in this case it seems hardly worth it as the attacks you can do with selector injection are by and large no worse than the deliberate functionality of letting an attack replace any named div with the text.


Incident Reporting or Notification Policy domain? I'm writing a company policy on how employees should handle reports of information security related events and notifications that come from vendors, customers, and from people within our organization.

e.g.

If a customer calls and says their data has been compromised and we're to blame
Someone receives unsolicited or suspicious e-mails from our domain.
Strange pop-up boxes on workstations
etc.

Note: We do not yet have a Incident Response Policy or Information Security Policy.

My question is should this type of document be a policy in its own right or a part of a larger Information Security policy or Incident Response Policy. I'm currently calling it a "Information Security Reporting Policy". Does this fall under an Information Security policy or Incident Response Policy or could it go either way or does it not matter as long as its written, clear, understood, and followed.

I wanted a simple, one page document that could be gone over with users through new hire training or by H.R..

Basically it states...

Document type of problem and description
Who reported? Ask for contact information (name, phone, e-mail) and consent to being contacted by security personal or management
Document date and time of occurrence
If applicable to situation ask for OS, browser, A/V, use of firewalls, use of wireless network etc.
How and whom to report to(escalate)

Should anything else be mentioned, removed, or modified? Does this sound reasonable, what are you thoughts?

Thanks
Jon

You're describing a procedures (i.e. "how do do X"), not a policy ("Do X").  As such the name of the procedure doesn't really matter.  What matters is that it references and is supported by one or more higher level policies.

An information security policy should cover far more than what you've described; I would be very hesitant to title your procedure "Information Security Policy" - that would be like labelling the keyboard "My computer".  The example is intentionally overstated, but if your company were audited and the auditors found your one-pager as the only document labelled "Information Security Policy", then you would have implicitly authorized all actions not covered by that policy.  (I don't know if your company is subject to audits. You've included a pci tag which leads me to believe that it is a possibility).

Generally the information security policy includes incident response policy.  Procedures are written to implement the policies.