Some of my published white papers in chronological order.

Cuma ve Cumartesi RIATalk's taydım ve iki konuda konuştum.

• Insecure Trends in Web 2.0 / Web 2.0 Uygulamalarında Güvenlik Sorunları
• Flash Uygulamalarında Güvenlik

Etkinlik Bahçeşehir üniversitesi Beşiktaş kampüsündeydi. Okunacak değil de daha çok tatil yapılacak bir yer tadında harika bir manzarası vardı. Özellikle benim gibi uzun süredir denizden uzak kalan biri için boğaz manzarasında kola yudumlamak büyük bir keyifti.

Birinci sunum olan "Web 2.0 Uygulamalarında Güvenlik Sorunları", "Kurumsal" sunumların yapıldığı daha küçük olan salondaydı ve çok daha keyifli geçti, katılımcılar hem sunum sırasında hem de sunumun sonundaki fikir paylaşımı kısmında tam bir harikaydı. Buradan teşekkür ederim kendilerine de.

İkinci sunum ise "Flash Uygulamalarında Güvenlik" ti. Sunumun içeriği gereği çok fazla teknik bilgi vardı ek olarak güvenlik ile ilgili bilgiye de ihtiyaç vardı, dolayısıyla kendimi CSRF, XSS nedir' i anlatırkem buldum ki bu da tüm sunumu teknik olarak iyice karışık yaptı. Buna rağmen fena geçmedi ama bir daha katılımcıların %80' inin rahatça takip edebileceğine inanmadıktan sonra bu kadar teknik sunum seçmemeye karar verdim. İkinci sorun salon o kadar büyüktü ki sahnede de değilde televizyonda sunum yapıyormuş gibi hissettim. Buna rağmen bir çok kişi iki sunumun da çok güzel olduğunu söyledi, her ne kadar ben ikinci sunumda tuhaf hissetsem de o aslında iyi geçmiş.

Bunun harici bir çok eski arkadaşımı gördüm, yeni süper insanlar ile tanıştım, bir de konferans sonu arkadaki cafe' de gizli bir güvenlik toplantısı da yaptık. Dolayısıyla arada sosyalleşme şansı da buldum. Türkiye' nin internet camiasının yakınlığını acayip seviyorum, sanki herkes birbirini liseden beri tanıyormuş gibi.

İki sunumun da hem slaytları hem de videosu online olacak. Insecure Trends in Web 2.0 zaten ingilizce olarak üzerinde çalıştığım bir makalenin türkçe sunumuydu, dolayısıyla çok daha detaylı bir makale o konuda gelecek inşallah.

Aşağıda RIATalks hakkında konuşan blogların adreslerini veriyorum. Sunum ve videoları bekleyemeyenler için bazı yazılarda benim sunumlarımın teknik detayları da var.

• Selçuk Hoca - RIATalks İstanbul İzlenimleri - I
• Selçuk Hoca - RIATalks İstanbul İzlenimleri - II
• Ahmet Eyüp - RIATalks İzlenimleri
• Riatalks, Snooker and Joker (ingilizce)
• Arman Acar - RiaTalks Ardından
• Bonus olarak şu twitter mesajı :)

Fotoğraf için Arman Acar' a http://www.flickr.com/photos/el3ctro/2748829625/ ya teşekkürler.

Daha önceden pek çok kişi zaten söyledi güvenlikçi olmak sadece birkaç teknik konuyu iyi bilmek ya da birkaç kitap okumak değil daha çok beynin nasıl çalıştığı, bir soruna nasıl yaklaşıldığı ve olaylara bakış açısı ile ilgili. Bunun yanında bir çok başka meslekte de gerektiği gibi gündemi takip etme, odaklanma ve havadaki kokuları alabilme de gerekli meziyetlerden.

Bir güvenlik uzmanının ya da daha spesifik olarak penetration tester’ ın bir dizi özelliğe ihtiyacı var. Bu özelliklerin bir kısmı teknik, ve teknik şeyler öğrenilebilir ama bir kısmı da doğuştan gelen huylar ve muhtemelen ne yaparsanız yapın öğrenemeyeceğiniz ya da gerçekten öğrenmesi seneler sürecek şeyler.

Konuyu burada hemen “güvenlikçi oılunmaz, güvenlikçi doğulur(!)” a bağlamak istemiyorum, çünkü durum bu değil. İddialara göre Mehmet Akif Ersoy demiş ki “Şiirin %5 ilham, %95 çalışmaktır”. Ben de bu şekilde düşünüyorum, dolayısıyla %5 + %95 e erişince Mehmet Akif Ersoy olunuyor.

Yazacaklarımın bazıları gerçekten ölümcül bazıları ise sadece işinizde daha iyi olmanızı sağlayacak şeyler.

• Güvenlikçi Olarak Yaşamak, Güvenlikçi Olarak Düşünmek
  • Yapmak değil, yıkmak
  • Kullanmak değil, Suistimal etmek
• Derinlemesine Bilgi
• Paranoya
• Tutku
• İletişim Becerisi
• Okuma

Penetration Testing, Güvenlik Uzmanı ve Vulnerability Assessment

Yazının detaylarına geçmeden önce bazı terimleri temiz şekilde ifade etmek gerekir.

Penetration Testing (Pen Test)
Bir sistemi dışarıdan genelde ekstra hiçbir ekstra bilgi sahibi olmadan güvenlik açıklarına karşı test etmek ve bu açıkları mümkün olduğu kadar exploit etmek.

Vulnerability Assessment (VA)

Aynı penetration testing gibidir ama açıklar exploit edilmez, burada dikkat edilmesi gereken bir nokta var ki Vulnerability Assessment daha çok false positive verecektir ve açığın gerçek etkisini ortaya koymayabilir.

Mesela test edilen sistemdeki Buffer Overflow açığı olan bir SMTP server varsa ama karşıdaki sistem x64 ise ve bu açık x64 da geçerli değilse Vulnerability Assessment bunu açık olarak direk kabul edecektir ama gerçekte bu açık exploit edilemeyeceğinden direk bir risk taşımamaktır. Buna rağmen eski versiyon bir yazılım bulundurmak genelde iyi bir fikir olmadığından VA’ ın sonuçları her şekilde işe yarayacaktır.

Güvenlikçi / Güvenlik Uzmanı

Güvenlik Uzmanı çok geniş bir terim genelde şu iki anlamda kullanılır:

• Bir sistemin güvenliğini sağlamadan sorumlu kişi.
• Güvenlik işini bilen kişi.

İroniktir ki genelde güvenlikçikler sistemleri korurlar Penetration Testerlar gibi saldırmazlar ama bu grubun ikisi de Güvenlikçi, Güvenlik Mühendisi, Güvenlik Uzmanı diye geçebilir.

Ek olarak bazı güvenlikçiler kendi sistemlerini test etmek için kendi içlerinden kendi sistemlerine saldırganmış gibi de test edebilirler. Bu kişiler genelde iki rolüde üstlenmiş olurlar. Not düşmek lazım bu aynı kendi programınızda “bug” aramak gibidir, yani muhtemelen iyi sonuçlar vermeyecektir. Yazılımın sahibi olarak yazılımın zaten doğru oldu varsayımı ile yola çıktığınızdan genelde önünüzdeki sorunları bile göremeyeceksinizdir.

Güvenlikçi Olarak Düşünmek

Polisiye filmlerdeki klasik muhabbetlerden biri “profiling” dir yani saldırganın profilini çıkartabilmek. Buradaki en büyük klişe ise bir dedektifin saldırgan gibi düşünmesidir. Ne kadar klişe olsa da bu gerçekten saldırgana ulaşmanın en iyi yoludur ve güvenlikçi de aynı periyoddan çok daha güçlü şekilde geçer.

Çünkü bir polis gerçekte saldırgana ulaşmak için kimseyi öldürmez ama güvenlikçi siteye girer, exploit eder, database’ i indirir, reverse shell’ ine erişir. Gerçekten suçu işler, doruğa çıkar ve iner. Bu gereksinim güvenlikçinin içerisinde saldırgan kimliğinin bire bir yaşamasını sağlar.

Bilinen bir gerçek bir çok büyük güvenlik firmasında çalışan kişilerin eski suçlu hackerlar olduğudur.

Örnek isterseniz Kevin Mitnick’ in kendisi ya da eski @stake’ in L0pth Heavy Industries hacker grubunda gelen tayfası güzel bir örnek olacaktır. Bu örneklerin yanında diğer bir çok benzer güvenlik sektöründe çalışan kişinin de karanlık bir mazisi vardır. Bu arada not düşmek gerekir ki bu furya değişiyor, yazının ilerisinde ona değineceğim.

O zaman güvenlikçi saldırgan gibi düşünmelidir, Saldırganın motivasyonu nedir?

• Para,
  Karşıdaki sistemi kırıp elde edeceği getiri (Kredi Kartı vs.)
  
• Şan / Şöhret,
  Cyber Grafiti veya benzeri gösteriler, Saldırgan sistemi kırabildiğini tüm dünyaya gösterir
  
• Ego Tatmini,
  Saldırgan karşıdaki sistemi kırıp kendisinin sistemin geliştiricilerinden daha iyi olduğuna inandırır, ek olarak kırılamayanı kırmış yeni bir şey yapmıştır.
  

Peki aynı durumda penetration tester ne yapmaktadır, onun motivasyonu nedir?

• Para,
  Sistemi kırmak, kontrolleri geçmek güvenlikçinin pozisyonun koruması ya da daha iyi bir tester olup daha çok maaş alması demek.
  
• Şan / Şöhret,
  Konu ar-ge olunca durum tamamen aynıdır, güvenlikçi yayınladığı yeni bir bir makale, araştırma yazısı ile o çevrede ünlenecektir, aynı şekilde saldırının başarısı ile de firma ya da kendi içerisinde bulunduğu grup içerisinde ünlenecektir.
  
• Ego Tatmini,
  Güvenlikçi bu noktada saldırgan ile birebir aynı duyguları paylaşır.

Görüldüğü üzere güvenlikçi ile saldırgan tamamen aynı duygular içerisindedir, dolayıyla penetration tester’ lar dünyadaki saldırgan rolünü direk olarak oynayan sayılı mesleklerin birini icra etmektedirler.

Yazının devamı gelecek inşallah, orada biraz daha psikolojik farklılıklara, daha verimli olmak için yapılması gerekenlere ve en sonra olarakta kendinizi bu alanda nasıl geliştirebilirsinize ve Derinlemesine Bilgi, Paranoya, Tutku, İletişim Becerisi, Okuma konularına değinmeye çalışacağım.

One of the cardinal rules of the web application security is "Do not trust the user input" but it's loosely defined. We should've said "Do not trust any input!"

Which input is coming from the user?

Web applications are more complicated than they were. Now we have got office applications and shiny Web 2.0 stuff all over the web. Complexity comes with a price tag and lots of hidden layers.

A perfect example of a hidden layer is the second order injections where the injection goes into a back-end storage, then directly pulled out from there and used in an SQL Query, printing out to the HTML without filtering or something similar. In this level developers believe that data was secure, because it was coming from a back-end, which was supposed to be secure. Guess what, it's not!

The fact is you can't keep track of your inputs, your input can come from an API that you exposed to your users, an old form which is adding records your db etc.

First defence would be centralising the input as much as possible, duplicated code is a big threat for security, but this is not enough. You need think "defence in depth" and you should not trust any input. It can be coming from the functions of your programming language, your database internal variables or from your web server, Do not trust any input!

Recently a CSRF vulnerability spotted in twitter. Twitter has two post screens, one of them for mobile and one of them for normal web browsers. Even though they put a CSRF protection to the normal page, they forgot to put this to the mobile interface. A perfect example of how code duplication can hurt your application's security.

About couple of months ago I was working on an application and observed that an ASPX file actually doing an HTTP request to itself and then it was printing the response in the page. First question was “How the script would know where is it running from? Which host? Which exact URL?”

The answer was quite obvious: Request.Url, Follow up question was “How ASP.NET would figure out what's in the Request.Url?”. The answer was: "Host Header" of the request. Which means if the target application configured to response all requests for that IP address then you can change the host header to anything you want to accomplish following actions:

• Using this system as a proxy to browse internal network by sending HTTP requests around,
• Abusing trust relationships in the internal network and in the very same computer, A perfect example of this accessing ASP.NET error messages and trace.axd file which are only available to local IP address by default.

It's quite common to see rookie developers blindly trusts HTTP Headers such as HTTP_REFERRER or Cookies, Thus you can carry out SQL Injection attacks, XSS attacks via these channels easily. Experienced developers or more security minded developers are not so naive and they know one can easily modify these. Still it's quite common to rely on system functions or server functions to be secure, because they are coming somewhere you trust, right?

As shown in the previous example even the functions such as Request.Uri might be controlled by the attacker. Therefore you should not trust anything coming from anywhere...

SSL Implementation Security FAQ is about implementing SSL in web and desktop applications. This FAQ doesn’t cover issues directly related with SSL/TLS. Only covers issues related with implementing SSL in applications.

Most of these are common mistakes during the implementation of SSL in the applications. These recommendations are especially critical for e-banking, e-commerce and similar websites.

• Is it secure switch back to HTTP after login over HTTPS?.
• Can I put my Login form to HTTP and target my form to HTTPS?
• What’s the best way to secure an SSL website?
• How cookies and SSL play together?
• How to Implement SSL in non Web Applications?
• Should I implement SSL support to non Web Applications?
• Can I put an order form designed for offline usage to print over non SSL?
• Should I support weak ciphers?
• Can I support weak ciphers in web server level but restrict access to the application when someone uses weak ciphers?
• ActiveX Security and SSL
• Download, MD5 Signatures and SSL
• Trusted Zone Required Applications and SSL
• 3^rd Party Browser Add-ins and SSL
• Why mixed content (HTTP and HTTPS) is dangerous in one page?
• Should I trust websites which pops-up some SSL warning?
• Is SSL just for authentication required applications?
• Is SSL only about Encryption?
• Should I disable HTTP access?

Is it secure switch back to HTTP after login over HTTPS?

No it is not. All communication during the authentication and after authentication should be over SSL.

There are several reasons:

• After login authenticated pages might include private information;
• To able to keep you logged application should use some sorts of session cookie. This can be over URL or in HTTP Headers but it doesn’t matter where it is an attacker can see it and use it. Which will cause an attacker to hijack active session and use. This can be done in several ways. If application uses a session hijacking protection XSS Tunnelling can help an attacker to bypass this protection.
• An attacker can change responses in the authenticated section and can show a login screen and may require user to enter they password again and steal their passwords. This can be done by injecting a JavaScript to HTTP responses.

Previously this mistake has been done by Google Gmail.

Can I put my Login form to HTTP and target my form to HTTPS?

No, that’s just a terrible idea and almost pointless. This is common mistake has been done by several major websites such as Godaddy.

• An attacker can modify response before arrives to user and then inject a piece of JavaScript code to steal credentials before user submits it. MITM possibilities are endless there are several ways to do nasty stuff in this situation.
• User will not know that they are sending the form to HTTPS URL thus they might believe something is wrong or even worse they might get used to it and fall for any phising attack over HTTP.
• Website users should stick with one URL to login and form URL and the target URL should be over SSL.

What’s the best way to secure an SSL website?

Disable HTTP access to the domain, don’t even redirect or link it to SSL. Just inform the users this website is not accessible over HTTP and they have to access it over SSL.

This is the best practice against MITM and phising attacks. This way your users will be educated that application never accessible over HTTP and when they come across to a phising or MITM attack they will know something is wrong.

One of the best ways to protect your application against MITM attacks and phising attacks is educating your users.

How cookies and SSL play together?

You should always mark your cookies as secure. Otherwise you’ve got a big security risk. Marking cookies as secure will prevent browsers to sending cookies over non SSL connections.

An attacker can force someone to do a connection over HTTP to steal their cookies and generally cookies carries of session critical information such as Session ID. Thus preventing this attack and marking cookies as secure is quite important.

How to Implement SSL in non Web Applications?

Your application should not trust non-valid certificates, if you allow this MITM attacks will be successful against your application. Depending application features and requirements this can lead Remote Code Execution easily.

I’ve seen this problem in many of bespoke applications. Generally developers leave support for non-valid certificates for testing purposes and deploy it like that. By default many of the underlying API won’t accept connections to non-validated certificated applications, it’s a good idea to keep it like that.

Should I implement SSL support to non Web Applications?

Yes you should, depending on the functionality it’s quite possible to do remote code execution because of non SSL connections.

Two following actions are highly vulnerable to this problem:

· Auto-update functionality of the application,

· Rendering a remote HTML in local-zone with Web Browser Control or in a similar control. Don’t forget every application is vulnerable to Cross-site Scripting if they are not over SSL!

Firefox was vulnerable to this, another similar one identified in a Vista Gadget.

Can I put an order form designed for offline usage to print over non SSL?

You might think putting a simple order form without a submit but designed to print and post over non-SSL could be secure, but guess what it’s not secure at all!

An attacker can inject a piece of JavaScript to this request, can log every single keystroke and send them to attacker’s website automatically. Thus you shouldn’t put an order form or any similar form which requires private information such Credit Card details, address, phone numbers etc.

In a similar way putting an offline order form such as PDF file to over non-SSL URL is another bad practice since attack can send this PDF file on the fly and modify post address or similar information to get benefit out of it.

This is common problem with banking websites where they provide these kind of forms over non-SSL connections.

Should I support weak ciphers?

No you should not. Main reason behind of supporting these ciphers is supporting old browsers but supporting old browsers is a terrible idea since the internet is full client-side exploits for old browser.

Which means a user with an old browser is potentially infected by a malware already. Remove support for weak ciphers from your web server.

Paypal announced that they don’t support old browsers any more.

Can I support weak ciphers in web server level but restrict access to the application when someone uses weak ciphers?

No you should not do that. This is a process where web server supports connection with weak ciphers but application informs that user can not continue unless they change their browser and come establish a new connection with a stronger cipher.

These ciphers are called as “Weak Ciphers” because they feasible crackable with a decent computing power. Basically a data transmitted over weak ciphers are highly vulnerable to cracking. Therefore an attack can sniff this data then crack and view transmitted data later.

This is dangerous because depending on the application, it might transfer cookies in these weak cipher used connections, (obviously including cookies those marked as secure). Even though application will inform to user that they can not keep using application this first request will send HTTP request over non-SSL connection and an attacker can see this request.

An attacker can be for victim to do this first request over another website in many different ways such as iframe. It’s enough for an attacker to modify one HTTP response on the fly to accomplish this.

ActiveX Security and SSL

If your application requires a custom ActiveX and if your ActiveX allows you to do something more privileged than normal a browser such as reading local files, executing certain OS commands then you should limit your ActiveX execution to only your domain.

If you limit your ActiveX only for your domain but not only for your domain and HTTPS access then an attacker can do MITM attack and can call this ActiveX over your domain and can use all functionality of the ActiveX. Obviously this can lead vulnerabilities such as arbitrary file reading from local file system, code execution or information leakage.

You should restrict your custom ActiveX applications to your own domain and SSL. This will stop this attack.

Download, MD5 Signatures and SSL

There of lots websites providing hash signatures of files, this is good for especially confirming the integrity of file against file corruption and similar issues. But if you put your files over HTTP then you should know that those hash based signatures are meaningless from security point of view.

An attacker can change file as well as the hash signatures on the fly.

Trusted Zone Required Applications and SSL

Some web applications require adding them to users Internet Explorer’s Trusted Zone list. This allows them to do more privileged actions such as installing ActiveX controls or writing local file system.

This is bad practice anyway and you shouldn’t do this unless you have to. If you have to this you should inform users that they should add your website to the trusted list with HTTPS not HTTP.

Any user with an HTTP entry in their Internet Explorer Trusted Sites list is vulnerable to remote code execution attacks. It should be noted that since IE 7 Trusted Zone a lot more secure than IE 6 and may not allows remote code execution by default.

3^rd Party Browser Add-ins and SSL

HTTP/1.1 RFC 2616 clearly states that clients should not include HTTP Referrers to connections over SSL:

Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.

Reasons are:

• Leaking sessions over URLs - critical;
• Leaking private information in URLs.
• Some 3^rd party add-ins for browsers such as Not Public Yet leaks SSL URLs by sending current URLs to their server over HTTP. This is not the very same thing but exactly very same affect.

This means when a user browses a web application over HTTPS, this add-on will send current SSL URL to their server over HTTP. Therefore attackers can see this URL and this is clear breach of URL privacy in SSL.

Why mixed content (HTTP and HTTPS) is dangerous in one page?

Browsers pops up a warning box when a page calls HTTP resources over an HTTPS URL. This generally happens if you try to include external JavaScript or Flash resources from an HTTP URL. This is bad because an attacker can do MITM to HTTP content and execute JavaScript in the same domain. This is very simple especially if this warning causes because of an external JavaScript resource.

Should I trust websites which pops-up some SSL warning?

Depends on the details on the warning, but simply No you should not. This generally indicates one of the following problems;

• SSL Certificate is self-signed;
• SSL Certificate is expired;
• SSL Certificate has been changed;
• Someone is doing MITM attack, which causes you to get not correctly signed SSL Certificate;
• Some of the content in the same page coming over a non-SSL channel.

All of these are not good and you shouldn’t trust them.

Is SSL just for authentication required applications?

No, if you consider the transmitted data between you and the visitors as private you should use SSL.

Most of the following component should always be over SSL:

• Authentication and after authentication pages;
• Contact Forms;
• Search forms and result pages.

Search and results pages maybe looks like overkill to you but imagine you open all of your google searches to public. I bet you don’t want to know people about your deep obsessions, health status, your applications error messages, your home address (google maps), your phone number etc.

Is SSL only about Encryption?

No, it’s also about identification. You can use SSL to prove who you are by getting certificate from a trusted CA by common browsers. Therefore your visitors can check your company name and details by looking into the details of your certificate.

Even though this is not bullet proof solution because of social engineering someone else can come with similar domain name and valid certificate and can carry out a phising or similar attack, even though this is another layer to protect your application against phising or similar attacks.

Also you can use SSL to identify a client to the server.

Should I disable HTTP access?

Yes you should, this is the best practice you can do in SSL usage. Disable port 80/HTTP access to your web server. It helps to prevent phising attacks, will educate users to stick with SSL all the time and will protect you against several wrong SSL implementations pitfalls.

Küçük bir sistem üzerinde çalışıyorum, Tag desteklemesini istiyorum. Veritabanını planlarken Tag kısmına gelince kafamda bir iki fikir canlandı. Hemen internetten diğer sistemlerin Tag desteklerinin nasıl olduğuna baktım. Özetle "Best Practice" leri incelemek lazım.

Tags: Database schemas makalesi süper 3 ana modelden bahsediyor ve basit şekilde artı / eskilerini irdeliyor. Tagschema diye de tamamen bu konuya odaklanmış deli bir blog var (oha artık sadece bununla ilgili blog mu olur!).

Tags: Database schemas makalesinden sonra benim aklımdakini ortaya koymak istedim nitekim sistemi de bu şekilde geliştireceğim. Muhtemelen bu model' de daha önceden yapılmış ve kullanılmaktadır zaten.

Kafamdaki yapı Tag + Trove Kategori sisteminin birleşmesi ile oluşmakta. Ancak Tag' ların serbestliğini kısıtlamamak için onlarda "Unattanded Tag" olarak girilebilecekler. Daha sonradan veya giriş anında gönüllü veya yönetici sahipsiz tagları ilgili kategoriler ile ilişkilendirebilecek.

Burada ortaya çıkacak sorunlardan biri iki kategoride aynı isme sahip olan taglar (mesela: grafik>rezil, programlama>rezil) karışıklığı. Aslında bu tag sistemi yapısının ana düşüncesini kırıyor mı kırmıyor mu tam çözebilmiş değilim. Örnek olarak bir makale "rezil" tagı içeriyorsa tüm diğer alakasız rezillikler ile de ilişkilimidir? Bir açıdan evet bir açıdan hayır. Bu durumdaki taglarada "Relative Tag" lar diyebiliriz. Bu da iki tip tag ve sonuç oluşturacaktır.

Database Yapısına bakacak olursak şu şekilde olmalı;

Post
-------------
id
title
post

TroveTag
---------------
id
parent_id
tag

TagAndPost
----------------
post_id
tag_id

Yeni bir post anında önceden olmayan Taglar oluşturulacak ve db' ye girilecek. Eğer önceden varsa onunla ilişkilendirilecek ("Relative Tag" sorunu burada soru olarak çözümlenmeli - ya da direk es geçilmeli)

Dezavantajlardan biri çok pratik bir query ile datalar çekilemeyecektir. Sonuç olarak elimizde Sonsuz kategori destekleyen gerçek kategorili ve Tag' lı bir sistem var. Bu da blog sistemlerindeki ikinci "kategori" tablosunun ortadan kalkmasına ve sınıflandırma sisteminin tek yerden kontrol edilmesine de izin veriyor. Ek olarak postlar arasındaki ilişkilerde daha kesinleşiyor. Mesela bu yöntem ve biraz ekstra SQL ile "ilişkili yazılar" çok daha verimli şekilde sunulabilir.