Jump to content
Killersites Forums

LSW
 Share

Recommended Posts

Web Developers, much of my posting to date has covered protecting yourself. Lets talk about protecting your customer and their users.

  1. I cannot state this any stronger, Strong Passwords! If it takes little effort to break a password than the site you built can be hi-jacked to pass out malware.
  2. Database design, consider making it a tiered design. Sensitive data in a red zone, encrypted and password protected with strict access permissions. Less sensitive data in a Yellow zone that has lesser protection and more access and simple stuff in a green zone with just password protection and general permissions. If you use look-up tables that state that "2 = married with children", that is a look-up table and needs liuttle protection. But all sensitive data should be encrypted so that if adversaries do get to it... they can't read it.
  3. Be aware of SQL Injection attacks. If you allow data to be added to a website, make sure it is checked. If you allow basic comments with no security, an adversary could insert JavaScript into that comment that does really bad things.
    Malware Detection - Discovering Cross-Site Scripting Attacks
  4. Watering Hole Attacks. I think LastLine blog defined it rather well: "In a network watering hole attack, cybercriminals set traps in websites that their target victims are known to frequent.  Often the booby-trapped websites are smaller, niche sites that tend to have limited security. These sites can include business partner sites or small websites that provide specific products, services, or information to the target company or industry. When visited, the compromised website infects the target end-users computer or device with keyloggers, ransomware, and other types of malware." The issue here is really about protecting web sites you build from being the water holes that infects your customers users.
    Network Security and Watering Hole Attacks

As I come across tips for securing your web sites, I will expand this thread.

  • Like 1
Link to comment
Share on other sites

  • 4 months later...

No,not really, web developer need to know how to correctly implement security measures and make sure it works just like the way it was intended to.developers doesn't need to study about cyber security in depth. There are standard practices which were supposed to be followed when it comes to security and a developer should keep that in mind.

Link to comment
Share on other sites

Cyber Security is a branch of it's own and I have been studying it for over a year now. Not only do they not need to know everything, but it would leave them no time to actually build web sites. Security is mostly the realm of ISPs, servers and hosts, but it is not something that you can ignore simply because you are "Simply the web developer". If they get hacked and it suggests it is do to something you did not do or did wrong, not good for your business. So aside from  making sure some simple rules are followed, it is a good idea to know that any Hosts you may suggest to a customer is trustworthy too. This is just 4 things web developers can do, I could suggest a lot more but that is more the hosts job.

I am a former web developer and these are things I did not consider back then.

Link to comment
Share on other sites

  • 5 months later...

Most of you think of cyber security as more attacks on your PCs and less a issue for web developers. You worry about keeping your PC and your data safe and worry about improving your design understanding and graphic skills. This is not a condemnation, before security and programming I was a web developer too until 2008 or so. I saw the world this way as well.

So finally, I have some fresh training under my belt on web applications, so here are my tips for you to keep your web sites and especially your client’s sites more secure. A good link for more info is http://www.webappsec.org/ as webapp security can be its own standalone job in the general world of cyber security.

 

The facts:

  • 2017 reports show that 21% of breaches were web-based attacks on sites and applications.
  • You need not be a target, just a means to a target. As you know, you can look at your web site as a folder on a server among many other folders, that is why it is cheap unless you pay for something more. So, if we both are on a sever and my folder is to hard to get into from outside, they will hack your site, one in your folder, they can laterally transfer into my folder once they are in the server. One person’s week security is a backdoor into everyone else’s web site.
  • By far, the most serious security vulnerability is SQL injection.
  • There is a 37% likelihood of Information Leakage being the first thing attackers look at. Data being shown that tells attackers what technology you use that they can use to get in.

 

Web Sites:

  • Predictable Resource Locations (PRL, 15%), by this we mean things common to computers, programs or even people. Attackers may just choose to enter a folder or document by typing it in, in a solid guess that it may exist.
    • /admin
    • .config.php
    • /web-console
    • /temp
    • /webdav
    • .bak
    • .old
    • .orig
    • .keep
    • .save
  • Standard Apache folder structure
  • Standard PHP folder structure
  • Robots.txt is another leak many of you should know the use of at least. Theoretically robots.txt holds a list of folders you do not want web crawlers to index for search engines. I used them thinking they could not hurt even if they are ignored by many crawlers. As a hacker, I have to wonder why you are hiding the folder ~joe from search engines? Must be something interesting enough to check out. It is not protected, and they are kept in the same place with the same name, so I just have to type it in the address bar and see what folders out there that you want to hide.
  • How about Directory Indexing that can get me to the contents of folders?

 

Web Servers:

  • Consider the Response Header of web pages, it holds useful information:
    • Date/timestamp can help narrow down where your server is.
    • It will show the server – example: Server: Microsoft-IIS/7.5. Now that you know the server, you can go to the National Vulnerabilities Database and find vulnerabilities for that version of IIS you can use to breach it.
    • It may show for instance what version of ASP.NET you may have used so you can find vulnerabilities for that.
    • It may show what CMS and the version and that can be used to find vulnerabilities for that version.
    • This data is there by default. You/your host must change the server settings in order to block such information
  • Verbose Errors Messages (technical errors messages):
    • You have seen these, the error messages that pop up in the browser but do not really tell you where the issue is. Find one and have a good look at it. See what info it is giving away to the viewer/attacker.
    • A typical one you are likely to see is the HTTP Status 500 error. Look at the data it is broadcasting to the attacker.
    • It may show anything from folder structure to scripts you have running and variables and processes you are using. Again, the more info the attacker has the easier to attack you.
    • Ensure that you have generic error messages in production that will not share info with attackers. You can still get the data from Logs for instance.
  • Keep all un-needed data off production errors, use generic error pages, have default server configuration inspected for security issues and finally, keep everything updated. The worst attacks of 2017/2018 were due to old servers or unpatched servers.
  • 300 Error Multiple Choices, this is when a server cannot find a page and may “suggest” pages. These pages may be unknown to the attacker but now been spotlighted by the server being helpful to the user.
  • Disable support for weak cipher suites, so only strong encryption is used. You want to disable support for:
    • RC4
    • Null Ciphers
    • Export Ciphers
    • Single DES
    • Triple DES
  • Use AES 128-SHA for TLS 1.0 & 1.1
  • Use AES 128-GCM-SHA256 for TLS 1.2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...