An error occurred while receiving the HTTP response to http://localhost:12345/SomeService.svc. This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details.

This evening I spent more time than I would care to admit working on a problem in a WCF Service I am building. The service has been working well for a number of weeks whilst it has all its functions ironed out; suddenly today after adding in one of those functions it stopped working in debug. I blame tiredness and a busy day in the office for me not realising the error faster, but for those who like me get tired here is the cause of the above error (or at least this version of the error).

[DataContract]
public enum LoginResultFlag {
    [EnumMember]
    Success = 100,

    [EnumMember]
    Failure = 200,

    [EnumMember]
    PasswordChangeRequired = 300,

    [EnumMember]
    AccountLocked = 400,

    [EnumMember]
    RequiresChallenge = 500,

    [EnumMember]
    SetupChallengeResponse = 600
}

Can you see the problem; it took me a little while of trial end error before I spotted it the moment I looked at the enum. Enums cannot be null, at their most basic they are integers and take the value 0. If you specify integer values as I have done here without adding a zero value then it cannot be serialized/deserialized through the web service boundary. All I had to do was add the following to the enum:

[EnumMember]
NotSet = 0

Problem solved!

The header image on this post was provided by Maria Freyenbacher on unsplash.com. Thank you Maria!

Read more

My work laptop is a first-generation Microsoft Surface Book (the 8GB model); it is by far the best laptop that I have worked with (both personal and professional). Granted there are better devices out there (a few Lenovo models come to mind) but I can’t afford them and my employer is unlikely to authorise them (getting the surface book required a guilt trip!).

Other than the first SB that I had suffering death within a few months (horrid grating fan noises, followed by a replacement) I have not had a single problem that wasn’t related to configuration or an old application not supporting HDPI screens. My employer’s system team can be a little slow at pushing out Windows Updates via WSUS (machines are blocked from accessing the internet variant of Windows Update); since the last “big lump of updates” my device received (I am guessing it included the last Win10 version update) the SBs fan noise has gone through the roof! Within minutes of turning the machine on (without even opening a program) the fans would be screaming along like they were cooling a data centre, and the back of the screen (where all the bits are) would get hot to the touch. After some google based research (and tying a few sets of instructions together) I have found what appears to be a solution!

#Shutting up the fans, and keeping a surface book cool! In their infinite wisdom Microsoft decided to teach Windows 10 that a device in the “Surface Family” is, in fact, a tablet computer (yes they can undock but they are largely used as laptops); to me this is silly. This includes a feature called “Connected Standby” which allows the machine to run in a low power state responding to the “on button” in much the same way as a smartphone or tablet. There are both plus and negative points to “Connected Standby”; one of the negatives being you lose access to all the normal Windows Power Management features (such as hibernate or sleeping).

Step 1: Disable Connected Standby

Disabling “Connected Standby” (CS for short) is as simple as flipping one flag in the registry.

This is a semi-technical article so I will not go into the perils of messing with the Windows Registry; if you are not comfortable in the registry please ask someone who is for assistance. You have been warned.

1. Start the registry editor (regedit.exe)
2. Locate the node “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power”
3. Set the key “CsEnabled” to 0 (zero).
4. Reboot

Step 2: Less is more

The SB is rather powerful for a low profile “2in1” machine; the problem here being that CPUs generate a lot of heat and that heat has nowhere to go inside the case. This means that the small fans inside the “screen case” have to run at insane speeds to force the hot air out of the sides. When the SB gets too hot (and the fans can’t cool it down fast enough) the processor is put into “thermal throttling”; in simple terms it has it’s maximum speed lowered to prevent damage from excess heat. This means that things take longer to process causing the heat buildup to last longer (the processor takes longer to return to an idle state).

Preventing the processor from getting into the “thermal throttling range” in the first place prevents the artificial slowdown. Many people will know what “overclocking” is, to deal with this problem we are going to use “underclocking”. Now wipe the shocked look off your face, lowering the maximum speed of the processor to prevent thermal throttling will actually give you a net gain in overall average speed! The game we will play here is finding that sweet spot which is low enough to prevent overheating but not so low that we notice the difference. I have found that 90% CPU is about the sweet spot.

How to under-clock the processor

You could use some complicated CPU Voltage management software (Intel provide a program for the SBs CPU), or you could play a less dangerous game and just use the Windows Power Configuration Manager that we unlocked by disabling “Connected Standby” earlier.

1. Right click on the battery icon in your task tray
2. Select Power Options
3. Depending on which power plan you have set, select “Change plan settings” alongside the active plan
4. Click “Change advanced power settings”
5. Navigate to “Processor power management > Maximum processor state” and set both options to no higher than 90%

Done, you have prevented the processor from reaching critical thermal levels. Before someone comments about it, I am aware this is not true underclocking but it has had the same effect.

Keep an eye on your CPU Temperature using a tool such as SpeedFan and adjust the percentage as necessary over the next few days until you find your devices sweet spot (all physical machines are slightly different, depending on what you do and how well it was put together!).

The header image for this post was provided for free by Hush Naidoo (@hush52) via unsplash.com. Thanks Hush!

Read more

This post is part of a series on HTTPS and browser security; it is partly to spread knowledge, but mostly to allow me to learn more about the subject by putting it ‘down on paper’! Enjoy, and please comment, correct, and discuss.

In the last post of this series I wrote about HSTS; like HSTS a Content Security Policy is a browser header (or a tag, but more on that later) which can be used to improve a websites security footing.

What is a Content Security Policy?

The easiest way to explain a Content Security Policy (CSP) is with the idea of a whitelist; whitelists act as an allowed set of values for a system. You may have heard of a blacklist before; a list of things which are not allowed, you employer/school will almost certainly have a blacklist of websites you are not authorised to visit (naughty or dangerous ones). A whitelist is the opposite; to use the website blocking analogy a whitelist would contain only the websites you are allowed to access (a much more restrictive setting than a blacklist).

A CSP outlines the resources which a website may use; this whitelist prevents any unauthorised or unexpected resources from being used on a website. These resources may be something as simple as a CSS or JS file served from your server, but they could also be dangerous injected javascript or hijacked third-party resources. A CSP is the first step towards mitigating the risk of unauthorised or unexpected page resources.

Whitelisting content sources

The CSP header is a simple list of resource types and the locations that are authorised to serve them. The most basic of CSPs would be:

Content-Security-Policy: default-src 'self'

This policy states that the website should only load resources from its own URL path (in the case of this page that would be melodiouscode.net). Any resource outside of that path (nastyhacker.com, googleanalytics.com etc) would be blocked by the browser. Although effective this policy is very restrictive; few sites only use their own resources and serving everything yourself is not the most efficient mechanism anymore (think of CDNs, Cloudflare, etc).

The CSP definition contains a number of restriction types, or directives, which can be used to fine-tune your whitelist.

Directives

There are a number of directives which can be used to tailor your websites whitelist the three obvious ones are:

• default-src: The default directive defines the fallback list of sources; used in the event that you do not specify a specific directive.
• script-src: The script source is perhaps the most obvious directive; it defines the list of sources which can load script files (javascript), including the use of inline scripts and the ‘eval’ command. By default inline scripts and ‘eval’ are disabled.
• style-src: The style source defines which sources can load stylesheets (CSS files), including the use of inline style tags and style attributes. By default inline styles are disabled.

In addition to the above three directives there are also directives for images, fonts, connect sources, objects, frames, and several others.

CSPs do not just act as restrictions for resource sources; there are also a number of directives which can be used to upgrade or improve the security of a website such as:

• require-sri-for: This attribute causes a browser to only load scripts/styles which have Sub Resource Integrity attributes set (more about them in a later module).
• upgrade-insecure-requests: As you would expect this directive encourages the browser to switch any HTTP requests into HTTPS requests where possible. For a full list of the directives and a playground for creating a CSP header, I suggest taking a look at the CSP Builder provided by report-uri. Report-uri.com is a fantastic resource for anyone using a CSP on their website; not only do they help you to get to grips with the policy but their services allows you to monitor how your policy is enforced.

Testing for and reporting on policy violations

Setting a policy without testing it would be a mistake; you may end up breaking your website without realising (you would have to test every page in every potential scenario to be sure it was 100% sure). Luckily there are two easy ways to review your CSP:

1. The browser console; all web browsers contain a console which script/etc errors are logged to. The console will list all the violations as they happen; a great way to test your policy on the fly. However not a great way to ensure your website works (other users will see a broken site whilst you are debugging it(.
2. The report-uri directive allows you to specify an endpoint to which the browser will send violation reports. The report-uri directive can be used in tandem with the Report-Only header which means that the browser will not actually enforce the policy; it will just report on the violations. It should not come as a surprise that Scott Helme’s report-uri.com also hosts a reporting endpoint (he did well getting that domain name).

Why use a Content Security Policy?

If your website only serves static HTML and uses no external elements then a CSP is unlikely to add much to your site. That being said it will also be easy to implement using the ‘default self’ rule!

However if your site uses external scripts over which you have no control then you should be using a CSP; or if your site allows users to enter information that is then displayed (comments, reviews, etc) you should also be utilising a CSP as an extra layer of defence against persistent XSS (cross-site scripting). If a user carefully crafts a comment to contain a piece of javascript and that comment is rendered back into the page a strongly controlled CSP will prevent the code from running (google ‘CSP nonce’ and ‘CSP hash’ for ways of dealing with inline javascript).

A well crafted and strict Content Security Policy, used in tandem with other best practices, will significantly reduce the risk of cross-site scripting (XSS) attacks.

Using a meta tag

I mentioned at the top of this post that a CSP can also be a TAG; not everyone has the ability to edit their browser headers. On shared hosting platforms, you are rarely given the ability to directly control the web server; some platforms such as GhostPro do not allow you any control over the server side configuration. The use of an HTML meta tag can help you to implement a CSP without having to set the actual browser header. The CSP “code” is the same as that for a browser header; the only limitation is that you can not use the report-uri feature to send failure reports. You can, however, look at report-uri.com’s JS which will perform the failure reporting for you!

Summary

In summary, if you run a website which presents dynamic content (be it a large corporate system, or a simple blogging/commenting platform) then you should also be using a Content Security Policy. It should be restrictive and ensure only expected and authorised hosts can be referenced in by your site. You should also make use of the report-uri functions (either self-hosted or using Scott Helem’s report-uri.com) to ensure that you do not cause errors on your website.

Read more

There is an old British saying “you can take that to the bank”; it means that the speaker believes something to be so truthful that the bank would accept it. It is believed to go back to when a cheque could be written on anything (it was simply a statement of intent) and it could be counterfeited with ease, but if it was definitely truthful then it could be “taken to the bank”.

Password security is critically important especially in the world of finance, and you can take that to the bank!

I went to my bank today (National Westminster Bank, or Natwest to us in the UK) to exchange some leftover Norwegian Krone, the most shocking thing I witnessed was not the exchange rate (I ended up with less than I started with after just a week). You guessed it; the most shocking thing I witnessed related to password security. At first look the security of my bank is rather impressive:

• There are big bars on the doors, and the walls are about four foot thick!
• The big thick glass between the public and the teller’s money drawer (a teller is a person who works at the counter).
• You must verify your identity with your card and pin before you start a transaction/conversation with the teller.
• My online account has two levels of a password, a random username, and a third factor for creating new events (paying a new person, changing settings, etc).

Unfortunately, this all falls apart in a way that the customer doesn’t normally get to see. If it had not been for a problem on the teller’s screen I would never have known about this failing and gone away happy with my “proper English money”.

Part way through my transaction the gentleman behind the counter informed me that he “had been logged out and will have to start again”; how odd I thought. He then informed that it “happens all the time” because they all use the same password.

I presume from the sentence “we all use the same password” that they also share the same username, else it is a hell of a coincidence. When someone else in the branch (I really hope it is one username per branch and not one for the entire firm) logged into the system the teller was kicked out and had to start again.

It seems that the system in question was a “separate application” and not part of the core banking applications. From the replies on twitter to my shocked tweet (thanks to Troy Hunt’s retweet) I have been informed that it would be a major breach of banking regulations if they shared accounts for the main systems; that being said encouraging password sharing for any system is just wrong and even more so in an industry such as the financial sector.

I'm sure it isn't, and I get the impression (obviously can't see the tellers screen from my side of the glass) that it was for "another system" due to the sort of transaction I was performing. I seriously hope the core systems are different!

— melodiouscode (@melodiouscode) May 1, 2018

I would not be surprised if the account is shared simply because there is a licence fee for the third party system they are using; sadly this is something we see all too often (I have worked at firms which do this on a regular basis).

I flagged this problem up with Natwest and they quickly came back to me for details, so hopefully they will sort out the problem and password sharing will become a thing of the past. Either that or the teller in question will get told off for letting me find out (I have told them that better not happen)!

Oh banks have a lot to learn about #passwords. I was just in @NatWest_Help and the teller had to start a process again as he was logged out of the system because "we all use the same password". I feel so secure..... No not secure worried, worried is the word I meant cc @troyhunt

— melodiouscode (@melodiouscode) May 1, 2018

The header image for this post was provided by @visuals_by_fred via unsplash.com. The screaming lady image was from @gmat07 also on unsplash.com. Thank you both Gabriel and Freddie.

Read more